Hello,
I use a STM32F777 configuration with LwIP stack and multitasking FreeRTOS, generated with CubeMX. By default there will be assigned a thread priority of 3 for LwIP threads (TCPIP_THREAD_PRIO, DEFAULT_THREAD_PRIO and SLIPIF_THREAD_PRIO). But a value of 3 will be interpreted as osPriorityRealtime (= +3) and assigned to an absolute priority value of 6 (highest priority level)!
So these threads are in immediate concurrence with the ethernet input thread ethernetif_input() and causing synchronization problems in preemptive multitasking OS:
Sometimes ethernetif_input() is interrupt in function HAL_ETH_GetReceivedFrame_IT() and OS is switching to tcpip_thread, that try to send a frame with function HAL_ETH_TransmitFrame() in low_level_output(). That fails because ethernet ressource is locked by the receiving function of other thread ethernet_input() in this moment (HAL_BUSY). Unfortunately the return code of HAL_ETH_TransmitFrame() is not evaluated, so this failure is very hard to find. This unsent ethernet frame causes a TCP retransmission with delay in communication (Wireshark).
I think the default thread priorities for LwIP threads, assigned in CubeMX, has to be lower than osPriorityRealtime (ethernetif_input() must have higher priority than concurrent LwIP threads). Otherwise synchronization between tasks of same priority will be necessary.
And the valid range for thread priority of LwIP threads in CubeMX is not 0...6, but like -3...3.
Evaluating return value of HAL_ETH_TransmitFrame() in low_level_output() would be also helpful to avoid unsent packets.
Can anyone from ST check this behaviour and confirm this for improving CubeMX in the future?
Thank you!
