Hello, I use stm32cubeIDE. And stm32f103 mc. In my project GPIO generates interruption which release the semaphore:
All my interrupts has a priority not above the priority set by configMAX_SYSCALL_INTERRUPT_PRIORITY == 5!
HAL_NVIC_SetPriority(EXTI4_IRQn, 5, 5);
Semaphore was created like:
buttonSemHandle = osSemaphoreNew(10, 0, &buttonSem_attributes);
In task i acquire the semaphore:
osSemaphoreAcquire(buttonSemHandle, 100) == osOK
Fnd after few task executes I get hard fault. If 100 change to infinity then I get harfault as soon as task acquire semaphore.
Hard fault happened at
xItemValue = listGET_LIST_ITEM_VALUE( &( pxTCB->xStateListItem ) );
In IDE -
Bus? memory management or usage fault (FORCED) Bus fault address register (BFAR): 0xa5a5a5a5
If do not use semaphores that is all ok. Where may be problems?
Have you defined
configASSERT and stack overflow checking as mentioned here:
FreeRTOS - Open Source RTOS Kernel for small embedded systems
Looking at the pattern
0xa5a5a5a5, it is probably a stack overflow. Try increasing the size of your task’s stack.
Another thing to watch out for is that you aren’t putting some of these objects on the main function stack, as that gets reused for interrupts.
configASSERT - stm32cubeIDE defined this macros. Sometimes also I get infinite loop in this macro:
configASSERT( pxQueue->uxItemSize == 0 ); in xQueueGiveFromISR function.
osSemaphoreNew(10, 0, &buttonSem_attributes) seems like allocate at heap.
pxQueue->uxItemSize == 0
was a symptom for stack overflows/memory corruption a couple of times here in the forum.
You should post the code of the function where you create the tasks.
Besides defining configASSERT do you have also stack overflow checking enabled (for development/debugging) ?
I tried running recursive factorial function that exactly get stack overflow and in cube I got corresponding error message. In semaphore case seems like no stack overflow.
I doubt that with
DEBUG_PRINT_MAIN enabled (using
printf internally if I’m right) a stack size of just 32 * 4 (= 128) is sufficient. I’d propose to try e.g. 1000 or more at least with
DEBUG_PRINT_MAIN enabled or remove the prints.