Ethernet communication and LwIP failed after some time (15-20mins). STM32H747

[SPate.11]

Hi Everyone,

We are using LwIP socket based API's to run server and client on STM32H747, both server and client are running on separate RTOS threads, the communication is fine for sometime after that it will wait forever for semaphore(RxPktSemaphore)  ethernetif_input() function.

Is there an Ethernet driver that has known bugs or is something else the problem?

Earlier we have followed How-to-create-project-for-STM32H7-with-Ethernet-and-LwIP-stack-working link to add LwIP and make Ethernet work.

we are using  STM32CubeIDE v1.6.1 and STM32Cube_FW_H7_V1.9.0

Regards,

Snehal

[Piranha]

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

On H7 Ethernet/lwIP implementation before the CubeH7 v1.10 was basically disfunctional...

[DOsbo]

Hi Piranha, we are still using your ethernet driver (thanks for that). As a side questions, do you know if it is safe to move back to v1.10 or does it still have issues?

Cheers

David

[SPate.11]

Hi @Piranha​  and Everyone,

Thanks for the following post,

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

We are able to make LwIP work on STM32H747, now communication is fine for the longer run, and the communication breakage is resolved.

Only on the Tx path, we are observing Ethernet packet data corruption, for the first Tx packet the data will be fine but from the next packet onwards data is corrupted, we are using socket API for communication from RTOS thread.

Second packet,

We have checked with UDP-based LwIP API and this Tx corruption is not seen, with socket-based LwIP API there is data corruption.

I have seen the following points, but not sure what change is required for low_level_output()

lwIP driver Tx missing D-cache clean operation.While a newer ST provided code solely relies on MPU to configure specific memory regions as non-cacheable, it is not a complete solution for Tx buffers. PBUF types PBUF_ROM and PBUF_REF can point to arbitrary memory addresses and therefore still need D-cache clean operation to be performed.

If this can cause by any other reason please let us know.

Regards,

Snehal