STM32CubeF4
STM32CubeF4 copied to clipboard
STMicroelectronics
STM32 lwIP Ethernet driver Tx deadlock
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
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.
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,
Hello @RJMSTM , any fixes? I have the same issue. I have been fighting with ethernet on stm32 for weeks nothing helps...
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.
Additional hit, when deadlock happens I get HAL_ETH_ErrorCallback instead of HAL_ETH_TXCpltCallback
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
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.
Hello,
With the HAL driver version 1.27.0/1, particularly in the F4 series where the Ethernet DMA cannot access flash memory, we are experiencing issues with flash access.
To ensure proper data copying from flash memory to RAM before processing, we recommend implementing the following modifications to your project:
- Define HTTP_IS_DATA_VOLATILE(hs) as TCP_WRITE_FLAG_COPY in the lwipopts.h file.
- If your project uses RTOS with Netconn APIs, use the NETCONN_COPY flag in the netconn_write API.
This issue is fixed in the STM32CubeF4 version 1.28.1.
With Regards,
