[bug fixes] STM32H7 Ethernet

[alister]

@Amel NASRI​, @ranran​, @Piranha​, @Harrold​, @Pavel A.​ 

V2 of my fixes and improvements to H7_FW V1.5.0/V1.6.0 Ethernet...

Changes include

• Decoupling receive buffers from receive descriptors so buffers may be held any length time without choking receive.
• Optionally queuing transmit, so transmit doesn't need to block until complete.
• Many bug fixes.

Find full details and source in the attached zip. V1 was posted to another developer's question. Please post any questions about V2 here.

[alister]

>I've tested the bug-fixed files but failed

Which is it? You failed to port the fixes or the fixes failed?

The shop I work have used these fixes/imrovements without problem more than a year in a product with moderate ingress traffic, many concurrent connections, UDP and TCP, bearing data, control and management. The fixes/improvements are good for us.

I'd be grateful if you'd share specific details. If there's a problem with the fixes/improvements, I want to know.

>today I tried as below.

You've prevented concurrent receive/transmit. With the material I've shared here it shouldn't take long to properly isolate and fix it. Without isolating it, you couldn't know your workaround is completely safe. Maybe its incidence is only reduced.

[DPark.6]

Porting was successful but my problem still occurs.

My MCU network traffic is about under 1mbps tx, 1mbps rx. (<- It's hard to generate problem but happens definitely)

To generate problem easily, I make more traffic 3mbps tx/rx. (<- Stop network service after 1~3 minutes)

Today I've test it for about 3 hours with my modification and have no problem until now.

I'll share more details that I've found.

[alister]

>I'll share more details that I've found.

If you include your H7 FW version, the are (hopefully function or even line) it's failing and the values of whatever you've instrumented/debugged that'd be great. Thanks

[DPark.6]

My H7 FW version is 1.8.0

[alister]

I don't use H7 FW 1.8.0. I've just diffed it on GitHub. Some of the easy bug fixes are attended. I don't see the unsafe call of HAL_ETH_BuildRxDescriptors in ethernetif.c is fixed. There's more than one ethernetif.c and I only checked Projects/STM32H743I-EVAL/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src/ethernetif.c, or perhaps I missed something.

You're using stock H7 FW 1.80, not the code described in this thread, observed some problem not described, which you've fixed with a semaphore. Perhaps your ingress rate's low, non-bursty and you've enough receive descriptors for your app and/or test method. Re semaphore, perhaps your protection's not implemented properly at input to tcpip_thread. This thread discusses the attached fixes/improvements to the Ethernet driver. Please open a new thread to discuss your journey with stock H7 FW. Thanks.

[ABlum.2]

Hello everyone,

I am trying to integrate this code into my code, but in the file stm32h7xx_hal_eth.c, in the function HAL_ETH_Init (line 345 I think) where the software set the bit to reset the MAC subsystems, it seems like the reset is not working, any idea on leads on how can I solve this problem?

Regards

Alan

[DBurr.1]

Which board are you using? Does it use the LAN8742 PHY?

[alister]

Perhaps get the H7 Ethernet peripheral and your MAC working with stock ST code first. Refer ST examples, manufacturer datasheet and Google for clues on the MAC. Then introduce my fixes/changes to the peripheral driver and lwIP interfacing.

[Piranha]

Most likely that is because the external MII/RMII clock is not present. Check the pin configuration and actual clock signal presence.

[ABlum.2]

Hi,

Thank you for the answer, I am using the Nucleo STM32H745ZI-Q, I think is compatible since with oder projects with the configuration of this LAN there is no issue.

Regards

Alan