STM32 lwIP Ethernet driver Tx deadlock

[superbool]

Describe the set-up CubeIDE version: 1.13.0 STM32CubeF4 version: 1.27.1 custom board: STM32F407zgt6 PHY: LAN8720A FREERTOS:10.3.1 CMSIS_V1 CMSIS_RTOS:1.02

Describe the bug tcpip_thread low_level_output wait on osSemaphoreWait forever.

How To Reproduce When running, try to interfere the RMII_REF_CLK GPIO(I'm using PA1) , connect to GND more than 3 seconds，app will never receive any data, and the tcpip_thread will go to wait and can't recovery。

Additional context My app work on hard condition, sometimes will interfered by some interference signal，as before just a reproduce contidion。 Or is there a way try to restart tcpip_thread or MX_LWIP_Init when something wrong? Not found the way, please help.

Screenshots

[superbool]

Additional context

When goto deaded, the DMASR register TPSS RPSS was 1, and I did't found any error handle code in HAL_ETH_IRQHandler about TPSS RPSS . How it happened, and how can i to recover the tcpip_thread by software.

[RJMSTM]

Hello @superbool,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With regards,

[klebol]

Hello @RJMSTM , any fixes? I have the same issue. I have been fighting with ethernet on stm32 for weeks nothing helps...

[danirpg]

Any update on this bug?

[hubert-melchert]

Hello @RJMSTM I'm using MCU package 1.28.1 and I can reproduce deadlock every time I issue a GET request to httpd. STM32F407, Stm32CubeIDE 1.15.1. Pinging the device works fine. I've enabled HTTPD in static configuration and when I try GET request then I get no response and low_level_output is stuck waiting for TxPktSemaphore. I've noticed that in case of any errors with ETH there is no scenario that would release this semaphore in void HAL_ETH_ErrorCallback(ETH_HandleTypeDef *handlerEth) Additionaly current implementation of low_level_output always return success even if HAL_ETH_Transmit_IT return error

We selected STM32F4 family assuming it's a mature platform for development but reading ST forum I come to conclusion that it is far from ready to develop ethernet enabled product on it.

[hubert-melchert]

Additional hit, when deadlock happens I get HAL_ETH_ErrorCallback instead of HAL_ETH_TXCpltCallback

[hubert-melchert]

Ok after some debugging and searching ST's forum I found out that: https://community.st.com/t5/stm32-mcus-embedded-software/http-request-to-stm32-lwip-results-that-ping-stops-working/m-p/144021/highlight/true#M8053 That was exacly my case, so moving this data to RAM helped. It's still frustrating that drivers can't handle errors and just gives a deadlock

[theadib]

For me the latest known working stack is CubeMX-6.4 and STM32F4-1.26.

After this CubeMX-6.4 I only had problems. The following versions introduced the BSP Phy kit. my 2 ct.

Let me know if you have a working solution. Adib.