This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83825I: Losing Ethernet Link (EVM)

Part Number: DP83825I
Other Parts Discussed in Thread: DP83825EVM

Hi Team,

We have the TI demo board and we connected with our application board, when we receive/transmit a large packet we are losing the Ethernet link.  We checked crystal clock and power supply looks ok and register too.

The issue is a bit random.

Initially I was polling BMSR register, and the Link_Status bit is randomly read as ‘0’.

It gets worse when transmitting many consecutive packets. Seems that increasing the data traffic on RMII is causing a link drop.

Then I found the same Link_Status flag in PHYSTS register but reading just it never returns ‘1’, either if the link LED is blinking and everything is working.

PHYSTS register returns a valid link (Link_Status = 1) only after a read of BMSR.

 

So for now the summary is that:

  • Connecting the cable  do not set PHYSTS Link_Status. A read on BMSR is needed in order to have good link status on PHYSTS.
    Disconnecting the cable cause PHYSTS Link_Status = 0. I do not need to read BMSR.
  • After a good link has been stablished, Polling BMSR randomly returns Link_Status = 0.
  • After a good link has been stablished, Polling PHYSTS Link_Status returns 0 only if I disconnect the ethernet cable. The random link down read in BMSR is not reflected in PHYSTS.

 

Therefore, now I am polling PHYSTS instead of BMSR, and if Link_State is ‘0’ I read BMSR to reset PHYSTS flag.

It seems stable, but I need to ask you:

  • Why PHYSTS reflects BMSR if I disconnect the ethernet cable and does not reflect the random link drop during data transmission?
  • How to properly pool the link status.

Regards,

RJ

  • Hello RJ,

    BMSR bit is latched low, which means if it goes low then it will stay low till we read this bit again. For example if the link is up, then during some event it goes down and comes back again, then reading BMSR link-status bit will show a "0" value (indicating that link was lost ) and will again go to "1" during the second read. This explains your following observations if the link is actually dropping :

    • Connecting the cable  do not set PHYSTS Link_Status. A read on BMSR is needed in order to have good link status on PHYSTS.
      Disconnecting the cable cause PHYSTS Link_Status = 0. I do not need to read BMSR.
    • After a good link has been stablished, Polling BMSR randomly returns Link_Status = 0.

    But the reason of following observation is not clear to me and I am checking with the team here about the possible reason :

    • After a good link has been stablished, Polling PHYSTS Link_Status returns 0 only if I disconnect the ethernet cable. The random link down read in BMSR is not reflected in PHYSTS

    --

    Regards,

    Vikram

  • And RJ as possible link-loss is happening during higher switching, can you also check for following on board:

    1. Is decap on VDDIO pin is as per datasheet recommendation?

    2. Do you have led_1 programmed to indicate data activity? If yes, can we try disabling it to reduce the switching noise on the board?

    --

    Regards,

    Vikram

  • Vikram,

    • 2. Do you have led_1 programmed to indicate data activity? If yes, can we try disabling it to reduce the switching noise on the board?
      - Yes, LED was programmed to blink but changing this didn’t solve the issue.

     

    • 1. Is decap on VDDIO pin is as per datasheet recommendation?
      - The DP83825EVM has the original decoupling caps but the power comes from our target board.
      I tried to use an external power supply and the problem incidence increased. My assumption is that the EVM ground is shifting during data transfer.

    From this assumption, I added a loop continuously reading BMSR with no interval in a high priority task and got 0xFFFF a few times during high data traffic on ethernet.
    As 0xFFFF should not be possible and I’ve got no errors from the MDIO peripheral, I am pretty sure the PHY got a bad address in the packet and did not respond at all.
    I added two more GND cables to decrease the total impedance and added another MDIO pull-up from in Target board. It is running more than 30 minutes with no drops.

    The 5cm wires from the target board to the EVM are probably the only issue but I have no way to improve these connections now.
    And why the same issue never happened when polling PHYSTS is still a mystery though.

    Regards,

    RJ

  • Hello RJ,

    Great debug. Just to be sure that I understood it correctly : issue is getting narrowed down to MDIO reads with ground bounce?

    --

    Regards,

    Vikram