Semaphore release leeds to hardfault

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.

I check 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.

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.

Code here:

Define semaphore:

Release semaphore:

Acquire semaphore:

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.