LPC546xx system asserts with disconnected ethernet

[andreschueer]

Dear Nxp, Dear community,

our system uses the lwip port from SDK 2.4.1 and regarding this issue we saw no change to newer SDK 2.5.

The problem is the following:

When our system has no ethernet cable connected, our firmware get's an LWIP_ASSERT in the lwip port.

"soup/lwip/port/ethernetif.c" line 433 - 347:

status = PHY_Init(ethernetif->base, ethernetifConfig->phyAddress, sysClock);
if (kStatus_Success != status)
{
    LWIP_ASSERT("\r\nCannot initialize PHY.\r\n", 0);
}

This lines seem correct on the first look, but inside psl_phy.c in PHY_Init in lines 119 - 131 the root cause of this problem is: 

/* Start Auto negotiation and wait until auto negotiation completion */
PHY_Write(base, phyAddr, PHY_BASICCONTROL_REG, (PHY_BCTL_AUTONEG_MASK | PHY_BCTL_RESTART_AUTONEG_MASK));
delay = PHY_TIMEOUT_COUNT;
do
{
    PHY_Read(base, phyAddr, PHY_SEPCIAL_CONTROL_REG, &reg);
   delay--;
} while (delay && ((reg & PHY_SPECIALCTL_AUTONEGDONE_MASK) == 0));

if (!delay)
{
   return kStatus_Fail;
}

So what it does is, active the Auto negotiation and wait until this is completed.

If the device times out, i.e. this happens when there is no ethernet cable connected, the PHY_init returns an error, which actually is somehow not 100% correct and this causes an LWIP_ASSERT which halts the whole system.

There is also a different thread regarding this issue which is similar but different:

K64F: System stops when ethernet cable isn't plugged in 

Here the solution was to disable the assert.

Is the solution for our problem the same and will this be fixed with the next SDK version or how should this error of not being able to auto negotiate being handeled correctly?

Our approach was to remove the lines in fsl_phy.c:

#if 0 /* Disable failure return. If auto-negotiation is timed out, this does not mean that the physical was not able to be initialized */

  if(!delay)

  {

    return kStatus_Fail;

 }

#endif

We simply want confirmation from NXP that this approach is also the fix that will be in a future SDK update.

[FelipeGarcia]

Hi Andre,

I hope you are doing great. Thanks a lot for your feedback.

I recommend you to check our next SDK2.6 REL 10 that it will be launched at the end of this month as estimated where this issue is fixed.

Have a great day,
Felipe

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------