NUCLEO-H755ZI-Q: Instability & long startup delay (1-3min) with LWIP/Ethernet after Power-Up

[Leo7]

Hello ST Community,

I'm currently working with a NUCLEO-H755ZI-Q board and trying to set up a stable Ethernet communication using LWIP without RTOS. Unfortunately, I'm encountering an issue with a long initialization time and subsequent instability that I can't quite figure out.

My Hardware & Software:

• Board: NUCLEO-H755ZI-Q

• Cube Firmware :  V1.18.0 (also tested with V1.17.0)

Configuration Steps in CubeMX/IDE (only for the M7, no changes for M4 made):

1. Created a new project for the NUCLEO-H755ZI-Q.

2. RCC: Set HSE (High Speed External Clock) to "Crystal/Ceramic Resonator".

3. Clock Configuration:

   • Configured System Clock (SYSCLK) to 400 MHz.

   • Adjusted all dependent clocks accordingly, ensuring CubeMX/IDE reported no clock configuration issues.

4. ETH:

   • Enabled Mode set to "RMII".

5. LWIP:

   • Enabled LWIP.

   • Disabled DHCP

   • A static IP address was configured: 192.168.001.123 with subnet mask 255.255.255.0

   • Selected "LAN8742" under "Platform Settings".

6. Generated code.

7. In the main() function, added the MX_LWIP_Process(); call inside the while(1) loop.
   

Observed Problem:

• Long Startup Delay after Power-Up: When I power the board via the USB connector, it takes approximately 1 to 3 minutes before the board successfully responds to the first ping from a PC on the same network.

• Stability after Initialization: Once this initial delay is overcome, the ping sometimes works stably and reliably.

• Behavior on Reset/ETH Reconnect: Interestingly, the long delay does not occur if I reset the board using the reset button or if I briefly unplug and replug the Ethernet cable (assuming the connection was stable before). In these cases, the ping response is almost immediate.

• Problem Returns after Power Cycle: However, as soon as I disconnect and reconnect the USB power supply (power cycle), the long 1-3 minute wait starts all over again.

• Sporadic Instability: Additionally, sometimes even after the initial stabilization, the ping connection suddenly becomes unstable (Request timed out) after several minutes of operation, until the board eventually starts responding again on its own or is reset.

• I also tried to power it via USB and put a Bridge on JP1 to make sure the STLINK is not the problem

My Thoughts/Questions

• PHY Initialization Delay: What could cause the PHY (LAN8742A) to take 1-3 minutes to establish a stable link only after a cold power-up? It works almost instantly after a software reset or Ethernet cable replug. Is there a specific initialization step, register setting, or timing dependency related to the PHY that might be sensitive to the initial power-on sequence?

• Cache/MPU Configuration Issues: I have already tried enabling I-Cache and D-Cache and configuring the MPU according to common recommendations/guides often linked for STM32H7 + LWIP + Ethernet setups (often involving specific memory region settings for buffers). However, implementing these changes resulted in the Ethernet communication failing entirely (no ping response at all). Are there known pitfalls or specific H755ZI-Q considerations regarding cache coherency or MPU settings when using Ethernet/LWIP that might explain this failure or the initial delay problem?

• Clock/LWIP Configuration: Could the clock settings (despite showing no errors in CubeMX) or the LWIP configuration itself?

• Has anyone experienced similar power-on delay behavior with this setup? What would be effective strategies to debug this further?

I appreciate any help or pointers!

Thank you in advance!

Best regards,

Leo

[mƎALLEm]

Hello @Leo7 and welcome to the community,

For efficiency purpose, please refer to this article: How to create a project for STM32H7 with Ethernet and LwIP stack working

Hope that helps.

[Pavel A.]

@Leo7 What is on the other side of the ethernet cable? Is it a "serious" switch with 802.1x support, for example? or a small "desktop" switch/hub? Do the LEDs on the switch port give any clue?

[Leo7]

@Pavel A.For the most part, I use a modern USB-C hub with Ethernet, but I’ve also tried it a few times with a cheap five-port network switch, the results were the same.
And the LEDs on the switch blink in sync with the pings.

[Guillaume K]

Hi 

When you write that you power the board with the USB connector, is it the STLINK USB connector or the USB charger ? (jumper 2 changed from default mode)

If you have changed the board configuration to get power from USB connector (not STLINK) then there is no reset sent to the LAN8742 PHY.

On this board it is the STLINK that sends RESET signal to the PHY. The case where the board is not powered with STLINK was not taken into account to send the reset signal to the PHY.

The reset button does send the RESET signal to the LAN8742 reset pin, thus the ethernet connection works quickly when the button is pressed.

A solution may be to do a software reset of the PHY when starting the application.

[Leo7]

@Guillaume K, thanks for digging into the power topic – I’ve already tried both power-supply variants described in the Nucleo manual, and I still see the 1-3 min link delay:

JP2 in position 1-2 (STLINK mode), USB cable on CN1 for the ST-LINK.
JP2 in position 7-8 (CHGR mode), USB cable also on CN1.
In both cases, the first ping after a cold power-up takes roughly two minutes, even when I press reset. 
How exactly would you do the “software reset” of the LAN8742?
I thought of some problems with the board itself, so I tested another one, with exactly the same behavior.

I also encountered the problem that even after the 2-3 min power-up delay, the connection wasn't stable for more than 10 minutes. Then it started to fail for 2-3 Pings, and sometimes it won’t reply to the pings until I reset it via the button.

Any advice on the reset sequence—or on the later instability—would be much appreciated.