Ethernet Initialization Hangs When Hardware Is Not Present

We are using an LPC4088 microcontroller with an Ethernet PHY (LAN8720) connected via RMII interface. The software stack includes MDK middleware version 7.12.0 and DFP version 2.2.2. The PHY is located on an Ethernet plug-in board.

When we call the netInitialize() function:

If the plug-in board is connected: netInitialize() returns success and Ethernet works as expected.

If the plug-in board is NOT connected: The code hangs inside netInitialize() and does not return.

Issue: We need a way to prevent the system from hanging when the Ethernet hardware is not present. Ideally, netInitialize() should return an error code or timeout instead of blocking indefinitely.

Questions:

1. Is there a recommended approach to handle missing Ethernet hardware in MDK middleware?

2. Can we configure a timeout or detect PHY presence before calling netInitialize()?

3. Are there any known fixes or patches for this behavior in version 7.12.0?

Parents
  • In an RMII interface, the PHY provides the clock for the EMAC peripheral. The netInitialize function does not contain an endless loop when the PHY is being initialized, so it is expected to return even in the event of a PHY error. However, the EMAC never exits its soft-reset state when the PHY is powered down or missing, because the required 50 MHz clock is not available. As a result, the software likely ends up in a hard fault exception caused by the missing clock.

    A practical solution is to verify the presence of the plug-in board before calling netInitialize. This can be done by reading an I/O pin—if available—that is connected to the plug-in board and indicates whether it is present.

Reply
  • In an RMII interface, the PHY provides the clock for the EMAC peripheral. The netInitialize function does not contain an endless loop when the PHY is being initialized, so it is expected to return even in the event of a PHY error. However, the EMAC never exits its soft-reset state when the PHY is powered down or missing, because the required 50 MHz clock is not available. As a result, the software likely ends up in a hard fault exception caused by the missing clock.

    A practical solution is to verify the presence of the plug-in board before calling netInitialize. This can be done by reading an I/O pin—if available—that is connected to the plug-in board and indicates whether it is present.

Children
No data