I using an STM32L4 series controller running freeRTOS. Execution stuck in configASSERT( uxSchedulerSuspended == 0 ) defined inside the vTaskDelay() function, which in turn is called by osDelay(). I am new to freeRTOS and request some help in directing to the underlying issue.
This symptom could be caused by a stack overflow / data corruption.
Did you also enable stack overflow checking for development/debugging. That’s very helpful !
Another reason can be wrong interrupt priorities for interrupts using FreeRTOS API in their corresponding ISRs resp. ISR callbacks.
See e.g. Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg for a pretty good explanation.
Please also share your call stack when the assert is fired.
Hello, Thanks for your input.
Increasing the stack size during thread creation solved the problem but couldn’t catch the stack overflow with the implemented hook function.
I have enabled stack overflow checking using configCHECK_FOR_STACK_OVERFLOW flag and implemented the hook function (vApplicationStackOverflowHook) in my application. The execution never reaches this hook function.
One BIG thing to remember with stack overflow checking is that it only catches the overflow after it has occurred, and only at the point that task is being switched out, so it won’t stop all problems. What it does it remove at least most of the cases where an overflow leaves a ‘delayed bomb’ that blows up later and you can’t see where the problem was. If the program ''crashes" immediately from the overflow stack, you at least have the data right there to see that it has happened (if you think to look).
Only using a ‘protected memory mode’ can overrunning the stack just immediately triggers a memory access fault gives you the immediate detection, and that requires using a processor with an MPU and writing your tasks to tolerate living in one.