Showing results for 
Search instead for 
Did you mean: 

FreeRTOS Priority Issue with ETH / LwIP (f746)

Associate III

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).


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.


As can be seen from the call stack, the scheduler is started,


Associate III

Follow up,

The issue went away when I completely reinitialized the CubeMX project.

I do not know what the original issue was though.

Associate II

I had the same issue and disabling the parameter USE_NEWLIB_REENTRANT helped. Maybe it'll be helpful for someone.