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?
