FreeRTOS Priority Issue with ETH / LwIP (f746)

[Mnemocron]

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

https://community.st.com/s/question/0D50X00009XkgpUSAR/problems-with-isr-priority-and-ethernet-stm32cubemx-freertos-lwip-

[Walid ZRELLI]

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

[Pavel A.]

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

--pa

[Mnemocron]

Follow up,

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

I do not know what the original issue was though.

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