nucleo-429zi ethernet Phy Sometimes fails auto-negotiation

[paulrbryson]

I am using a Nucelo-429zi board for development and my custom PCB schematic is based on this board.  I am experiencing a problem where about 10% - 20% of the time after a hardware reset the PHY will fail auto-negotiation.  The green led does not come on and the amber led blinks.  This happens even when on the debugger and the MCU is not allowed to run.  I only have one Nucleo board so I cannot try another to see if the problem is unique to this board.

Is this a known problem? seen before?

What could it be?  Possibly the clock circuit?

[sergey23]

If you can post the ethernet part of the schematic, and your ethernet firmware code snippet, that would help.

You could try to load Mongoose-based test firmware and see if the same happens. Visit https://mongoose.ws/wizard/#/output?board=f429&ide=CubeIDE&rtos=baremetal&file=README.md , select destination directory in the settings tab, click "generate" button on top right, load the project in Cube IDE, start serial console, and build & flash the firmware. Board's IP address should appear in the log, as well as the other debug info like PHY parameters, link speed, etc.

[paulrbryson]

I am using the nucleo-429zi development board.  I don't think firmware is involved.  This happens before the firmware even runs.  The phy chip either fails or succeeds at auto-negotiation even if the MCU is completely erased or is prevented from running by the debugger.  Once the phy chip has failed to auto-negotiate it does not recover.  I can repeatedly perform a hardware reset on the phy chip until the auto-negotiation succeeds.  But this seems like a hack rather than a solution and how do I know that board to board variations will not produce some units which never work?

This is the schematic for the nucleo board (also see attached)..

 

 

[paulrbryson]

I am not sure of the cause for the original problem - i.e. a hardware reset leaves the PHY in "bad" state.  I suspect it may have something to do with the internal 25MHz oscillator not stabilizing before auto-negotiation starts?  
In any event I found what looks to be a reliable solution - retstart the auto-negotiation in firmware after the PHY chip has stabilized.  I Inserted the following code in the stm32cubemx generated source, in "ethernet.c".

 

 

/* USER CODE BEGIN PHY_PRE_CONFIG */
 /* Force a PHY Auto-Negotiation -- Hardware Reset Can leave Phy in Bad state*/
 {
 /* PHY Register Definitions */
 const uint32_t NEG_LAN8742A_ADDRESS = 0x00U;
 const uint32_t NEG_PHY_BCR = 0x00U; /* Basic Control Register */
 const uint32_t NEG_PHY_BCR_SOFT_RESET = (1 << 15);
 const uint32_t NEG_PHY_BCR_AUTONEGO_EN = (1 << 12);
 const uint32_t NEG_PHY_BCR_RESTART_AN = (1 << 9);
 
 /* Implementation of the missing function */
 uint32_t phy_reg = 0;
 
 // 1. Send Soft Reset command
 HAL_ETH_WritePHYRegister(&heth, NEG_LAN8742A_ADDRESS, NEG_PHY_BCR, NEG_PHY_BCR_SOFT_RESET);
 
 // 2. Wait for Reset bit to self-clear (indicates PHY is ready)
 uint32_t timeout = HAL_GetTick() + 500;
 do {
 HAL_ETH_ReadPHYRegister(&heth, NEG_LAN8742A_ADDRESS, NEG_PHY_BCR, &phy_reg);
 } while ((phy_reg & NEG_PHY_BCR_SOFT_RESET) && (HAL_GetTick() < timeout));
 
 // 3. Force Auto-Negotiation Enable and Restart
 HAL_ETH_WritePHYRegister(&heth, NEG_LAN8742A_ADDRESS, NEG_PHY_BCR,
 NEG_PHY_BCR_AUTONEGO_EN | NEG_PHY_BCR_RESTART_AN);
 
 }
 
/* USER CODE END PHY_PRE_CONFIG */