LPC54S016JET180 lwip Ethernet gets stuck on PHY initialization and asserts after a while

[mibli]

We're having issue with using different pinout for Ethernet with lwip in our application and different pins from example. First I'll describe the failure state, and then I'll explain the pinout differences.

The code is basically same as in lpcxpresso54s018_lwip_ping_rtos. But the code gets stuck waiting at fsl_enet.c:1065:

while (ENET_IsSMIBusy(base))
{
}

During that time PHY_LAN8720A_Init is executed and in loop in fsl_phylan8720a.c:75

    /* Check PHY ID. */
    do
    {
        result = PHY_LAN8720A_READ(handle, PHY_ID1_REG, &regValue);
        if (result != kStatus_Success)
        {
            return result;
        }
        counter--;
    } while ((regValue != PHY_CONTROL_ID1) && (counter != 0U));

PHY_LAN8720A_READ returns success, however eventually the loop is exited with counter = 0 and we receive an assert.

I've experienced this behavior if the pinout was incorrect, however we've analyzed the pinout, compared it to the EVA board and it should be ok...

The pinout is same as in the example, with some changes, reflected from the client board:

Pin Signal	LPC540S018-EVA example	LPC540S016 on customer board
ENET_CRS		P2_2
ENET_RX_DV	P4_10
ENET_MDC	P4_15	P1_16
ENET_MDIO	P4_16	P1_17
ENET_PHY_RSTn	P2_26	// routed on board to reset
ENET_RX_CLK	P4_14	P4_14
ENET_RX_ER		P2_10 // also tried without
ENET_RXD0	P4_11	P4_11
ENET_RXD1	P4_12	P4_12
ENET_RX_EN	P4_13	P4_13
ENET_TXD0	P4_8	P4_8
ENET_TXD1	P0_17	P0_17

And with that pinout we've expected it to work, as P4_10, P4_15, P4_16 and P2_2, P1_16, P1_17, seem to support the same functions according to the LPC540xx LPC4S0xx data sheet:

PIO4_10: ENET_RX_DV – Ethernet receive data valid.
PIO4_15: ENET_MDC – Ethernet management data clock.
PIO4_16: ENET_MDIO – Ethernet management data I/O.

PIO2_2: ENET_CRS – Ethernet carrier Sense (MII interface) or Ethernet Carrier Sense/Data Valid (RMII interface).
PIO1_16: ENET_MDC – Ethernet management data clock.
PIO1_17: ENET_MDIO – Ethernet management data I/O.

We have also tried disabling P2_10, and forcing P2_2 to route ENET_RX_DV signal, the result is the same.

Are we missing some extra initialization code to be able to use these pins? If so I would be thankful for feedback, I didn't find anything about it in the documentation.

I'm attaching the call stack for the part that gets stuck, and the schematics of LAN8720A pinout on the client board. The connections were tested on site for correctness.

[HangZhang]

Hi @mibli 

According to the hardware schematic of LPC546xx and LPC540xx.  Although P4_15 and P1_16 support the same ENET_MDC function, the physical ENET_MDC connection of the LAN8720A only connects P4_15 and not P1_16, so if you want to use P1_16, you need to connect the ENET_MDC connection of the LAN8720A and P1_16 on the board.

Hope this will help you.

[mibli]

Hello @HangZhang. Thanks for Your reply.

I understand that You're referring to the evaluation board, however that's the behavior on custom board, where the second set of pins are physically connected to the LAN module, so there should be no issue with using them on that board.

Could there be a different reason?

[mibli]

As an update @HangZhang I've synced with my teamate and he says, that MDIO perhaps is communicating correctly now, we're getting stuck at fsl_enet.c:202 (ENET_SetDMAControl)

/* Reset first and wait for the complete
* The reset bit will automatically be cleared after complete. */
base->DMA_MODE |= ENET_DMA_MODE_SWR_MASK;
while ((base->DMA_MODE & ENET_DMA_MODE_SWR_MASK) != 0U)
{
}

From what we've read it can be caused by incorrect clocking signal. But could it be related to usage of P2_2 instead of P4_10?

[HangZhang]

Hi @mibli 

This should be caused by an incorrect clock, but we cannot reproduce this issue, so we don't know if it was caused by usage of P2_2 instead of P4_10. But we encountered a similar problem before, which is consistent with your phenomenon, and it was also stuck in this code segment. Below, I will write about the problem and its solution.

They use the LAN8720a which has a REFCLKO pin and is connected to the ENET_RX_CLK pin of the LPC. It turned out that the reference clock was not generated by the phy causing the LPC to be stuck in the ethernet DMA initialization. They fixed this by enabling this clock (pulling INTSEL down) on the phy and now it works correctly.

Hope this will help you.

BR

Hang

[mibli]

@HangZhang we did find issue with the clock on our board, and with fixing it, we were able to complete PHY initialization and got to the DHCP stage. However it still seems like we're unable to receive packages using P2_2 (configured in Pins tool) as a ENET_RX_DV or ENET_CRS (assuming it serves similiar function). The DHCP receives request and assigns the IP, however we receive nothing. Is it possible to use P2_2 in this way on this chip?

[HangZhang · Accepted solution]

Hi @mibli 

I checked the LPC540xx data sheet. PIO2_2 can only be reused as ENET_CRS, not as
ENET_RX_DV.

So i think it is impossible to use P2_2 in this way on this chip.

Hope this will help you.

BR

Hang