Showing results for 
Search instead for 
Did you mean: 

Error in the init of ethernet

Associate II


Good morning everyone!

I'm working on a project involving FreeRTOS, lwip, and Ethernet with the ST32H563VGT6 MCU on a custom PCB.

I'm attaching the hardware schematics, which we've taken from ST's schematics of the NUCLEO-H563ZI board. I'm including a PDF with the schematics distributed by ST.

The schematics of my board are shown below:



In previous versions of the custom board, we used a different hardware design:



We decided to switch to ST's schematics for greater robustness. The first configuration we tried, shown in the second image, is characterized by the lan8742 clock coming from the MCU's output clock (MC0), and the RJ45 connector comes with built-in magnets. Additionally, it does not include the USBLC6-4SC6 integrated circuit for ESD protection.

The second configuration, corresponding to the first image, uses ST's schematics, which we imported identically to the ST version of the NUCLEO-H563ZI.

With the ST configuration, we're experiencing an error in MX_ETH_Init():



  SET_BIT(heth->Instance->DMAMR, ETH_DMAMR_SWR);
  /* Get tick */
  tickstart = HAL_GetTick();
  /* Wait for software reset */
  while (READ_BIT(heth->Instance->DMAMR, ETH_DMAMR_SWR) > 0U)
    if (((HAL_GetTick() - tickstart) > ETH_SWRESET_TIMEOUT))
      /* Set Error Code */
      heth->ErrorCode = HAL_ETH_ERROR_TIMEOUT;
      /* Set State as Error */
      heth->gState = HAL_ETH_STATE_ERROR;
      /* Return Error */
      return HAL_ERROR;



The issue is that the SWRESET is not occurring, causing the timeout to trigger the error handler. Conversely, with the other configuration, this error doesn't occur, and initialization proceeds correctly, allowing DHCP negotiation.

We've even attempted a bypass, avoiding the use of the LAN8742 crystal (trying to replicate our first design which works) and relying solely on the MCU.

It's important to note that we're using the same program, the same firmware, the same version of CubeMX, and the same compiler at all times.

What could be causing the software reset not to occur?



> What could be causing the software reset not to occur?

Missing clock into STM32 (RMII_REF_CLK). The difference is in the strap on pin 2 (in its nINTSEL function, read LAN8742 datasheet).

I don't know (and am not interested to find out) how NUCLEO-H563ZI copes with it exactly - if you can get SMI (MDIO/MCLK) working, you can set LAN8742's REFCLKO to output the required clock through that interface.



"Hi JW,

I'd appreciate it if you could provide more details about the situation you're referring to.

The important info I have gathered from the datasheet is: LED2/nINT/nPME Usage with nINTSEL Disabled When the LED2/nINT/nPME/nINTSEL pin is low during reset, the nINT/REFCLKO pin is configured to function as REFCLKO. After the deassertion of reset, this pin will first function as LED2. Upon configuration, it can function as nINT or nPME. Figure 3.13 illustrates the steps required to program the LED2 pin as nINT or nPME with nINTSEL disabled. In this configuration, it is not recommended to connect an LED to this pin. Because this pin is active high, the LED will be lit while waiting for a WoL event.

and I should configure the nINTSELpin as:

3.7.4 nINTSEL: nINT/REFCLKO Configuration The nINTSEL configuration strap is used to select between one of two available modes: REF_CLK In Mode (nINT) and REF_CLK Out Mode. The configured mode determines the function of the nINT/REFCLKO pin. The nINTSEL configuration strap is latched at POR and on the rising edge of the nRST. By default, nINTSEL is configured for nINT mode via the internal pull-up resistor.


However, i am not able to fully understand it.

Please,  could you dig more in your answer?


Upon reset, the PHY sets pullups on certain pins and reads in their state, which is then stored in certain register bits and influence, how PHY works. In other words, the PHY is pin-programmable, to a certain extent, but to spare pins, the programming pins are not dedicated, but they are scanned at reset, and subsequently used for other purposes. This is result of years of PHY development and reduction of number of pins to absolute minimum. External pulldown resistors, used to override the internal pullups, are traditionally called "straps" (from the analogy with piece of leather at the rear top of the traditional leather boot, used to grab on when pulling on the boot).

In particular, the default function of REFCLKO/nINT pin is nINT; but this can be overridden by a strap (pulldown) on nINTSEL pin (pin 2), which ensures that the level on that pin during and shortly after reset is 0. This is latched at reset to an internal latch (in some other PHYs, this internal latch is exposed through registers, in LAN8742 it appears that there's no such register bit, so the only way to enable the reference clock output is through this strap). That clock is then used as input to your STM32 as the RMII reference clock; without that clock the softreset "hangs" (does not auto-clear) as you've described.


Associate II

Morning, JW.

Thank you for your detailed explanations, now I fully understand what you were saying.

However, if you look the schematics, you will see that there is already a pull down resistor on pin 2 (LED2/nINT/nINTSEL).


therefore, the reset should be performed correctly, right?

Should i change the value of the strap?

Then I don't know.

Start with measuring presence of the 50MHz clock on STM32 RMII reference clock input; if not, check voltage on the strap input (nINTSEL) and check if PHY's crystal oscillator works at all.

Also check connections of all VCCs and GNDs of the PHY, including the middle tab.


Good morning, Jan.

We've encountered an issue regarding the absence of a 50 MHz clock output on the RMII_CLK_REF. Instead, we're measuring a voltage range of 1.9 to 2.1 V at the VDDCR pin, whereas it should ideally be 1.2 V according to the datasheet. In our previous design and on the NUCLEO BOARD, the output reads 1.2 V as specified. As evident from our pictures, we're utilizing the internal Voltage Regulator (with REGOFF internally pulled down). This deviation from the expected VDDCR output voltage seems to be the root cause of our design issue. Although the crystal oscillator is functioning correctly, it appears to have a greater DC offset compared to the Nucleo Board. Comparison of LAN8742 crystal output:

  • NUCLEO Board:


  • Our Second Design:


Furthermore, we've observed that the nINTSEL pin is not performing as expected. During a reset period, the behavior differs between the NUCLEO and our second design. On the NUCLEO, the GPIO pin transitions from high to low for 25 ms before going back to high to initiate the reset. Conversely, on our design, the nINTSEL pin exhibits inconsistent behavior, with the GPIO pin initially at 1.2V before initialization, and the output of the nINTSEL pin deviating from its expected behavior.

Comparison of LAN8742 nINTSEL output:



  • nINTSEL OUTPUT from our second design:


Similar irregularities are observed with the REGOFF pin.

We suspect that these issues may be related to the malfunctioning of the internal regulator, resulting in incorrect VDDRC output.

We've thoroughly reviewed both digital and analog voltages, and they appear stable and within the specified range, except for the Ethernet Magnetics Supply Voltage (we don't know how to measure it)


Your support and assistance in resolving these issues are greatly appreciated.

Thank you,




Hi Maxim,

I'm by no means expert on the PHY. You may perhaps try to talk to SMSC/Microchip.

Meantime, as I've said above, check connections of all VCCs and GNDs of the PHY, including the middle tab.


Associate II

Ok, thank you.

Yes, I did it and all seems correct except for the VDDCR pin.

I will contact microchip support.