Hello, I use stm32cubeIDE. And stm32f103 mc. In my project GPIO generates interruption which release the semaphore: osSemaphoreRelease(buttonSemHandle);
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?
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.
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.