2021-04-04 02:22 AM
I develop a FreeRTOS / LwIP based application which throws a configASSERT error because of a bad priority.
Only when the Nucleo is connected to the LAN, the debugger gets stuck at:
Line 744 of port.c (FreeRTOS source)
configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );
Trace (see image below):
The origin of the interrupt is the ETH_IRQHandler() respectively the HAL_ETH_RxCpltCallback()
I have been searching for this issue and understand that it has something to do with interrupt priorities. Why does this error occur? As I see it, the function call causing it is auto generated by HAL or implemented in the CMSIS source (osSemaphoreRelease).
Can anyone give me a hint where to change something?
There are a dozen different priorities in the STM32/FreeRTOS System, which one do I need to change to avoid this assertion fail?
NVIC Interrupt Priorites are all below the RTOS max of 5 (see image below)
Changing then does not change the configASSERT error.
I am referencing this solution from 2018 which shows the exact same behaviour with the Ethernet connector. However, in my case the ETH Interrupt Priority is already at 9 (lower priority).
2021-05-06 03:56 AM
Hello @Mnemocron ,
Do you have one or more IRQ handlers that use FreeRTOS functionalities (posting to a queue, etc...)?
If so, make sure that the scheduler has already started before calling them.
You can use xTaskGetSchedulerState function to know if the scheduler has started or not.
I hope this helps.
Walid
2021-05-06 09:34 AM
As can be seen from the call stack, the scheduler is started,
--pa
2021-05-06 11:34 AM
Follow up,
The issue went away when I completely reinitialized the CubeMX project.
I do not know what the original issue was though.
2023-11-30 12:41 AM
I had the same issue and disabling the parameter USE_NEWLIB_REENTRANT helped. Maybe it'll be helpful for someone.