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?
"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:
3.8.1.4 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?
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?
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 NUCELO
- 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,
Maxim
