• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 86 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83867IR: Link is unstable: False Carrier interrupt and XGMII Error interrupt

Atsushi Takahashi
Expert 1415 points
Part Number: DP83867IR

Tool/software:

Hi Team,

The link is not stable when connecting the Switching Hub (PHY: Microchip) and Interface Unit A and C (PHY: DP83867IRRGZ).
The situation is as follows.
The link between the Switching Hub (PHY: Microchip) and Interface Unit B (PHY: Marvell) is stable.

Local Remote Link Status
Switching Hub
PHY: Microchip		 Interface Unit A
PHY: DP83867IRRGZ		 Cable Length 20m: OK
Cable Length 1-2m: NG
Interface Unit B
PHY: Marvell		 Cable Length 20m: OK
Cable Length 1-2m: OK
Interface Unit C
PHY: DP83867IRRGZ		 Connector connection: unstable

When connecting Switching Hub and Interface Unit A, the problem depends on the cable length, so the customer tried the solution described in the troubleshooting guide (3.1 Improving Link-up Margins for Short Cables), but it did not improve.
https://www.ti.com/lit/an/snla246c/snla246c.pdf

When connecting Switching Hub and Interface Unit A, they read Reg 0x000 to 0x001F when linking up (long cable) and when the link down (short cable), and we think the following registers shown when the link is down are suspicious.

Reg 0x0013: bit[8]=1: XGMII Error interrupt
Reg 0x0013: bit[2]=1: False Carrier interrupt

What causes these to occur?

In addition, the Switching Hub (Microchip) and Interface Unit A (DP83867IRRGZ) passed the 1000BASE compliance test.

Best Regards,

  • 0
    TI__Genius 12331 points

    Hi Takahashi-san, 

    Please use both scripts (3.1 and 3.2) and see if there are any improvements. 
    If not, I suggest changing 0053 2054 to writing 2053h to register 53h. 
    What does unstable connection mean for Unit C? Lastly, what was the register read of 0015h?

    Atsushi Takahashi said:

    When connecting Switching Hub and Interface Unit A, they read Reg 0x000 to 0x001F when linking up (long cable) and when the link down (short cable), and we think the following registers shown when the link is down are suspicious.

    Reg 0x0013: bit[8]=1: XGMII Error interrupt
    Reg 0x0013: bit[2]=1: False Carrier interrupt

    What causes these to occur?

    XGMII error is flagged when there is an error on the MII line. 
    False carrier interrupt happens when the PHY's receiver falsely detects some noise or other signal as a packet but it turns out not to be a packet. This may go up when the link goes down. 

    Best,
    J

  • 0 in reply to J
    Expert 1415 points

    Hi J-san,

    Thank you for your reply.

    You said:
    What does unstable connection mean for Unit C?

    The link keeps going up and down and the link status is unstable.

    You said:
    Lastly, what was the register read of 0015h?

    After which process does this indicate an action?
    After 3.1? After 3.2?

    You said:
    If not, I suggest changing 0053 2054 to writing 2053h to register 53h.

    I understand this is a 3.1 action.
    What is the difference between 2054h and 2053h?

    Is the XGMII error indication related to 3.1 and 3.2?
    As the name suggests, I understand that MII is a media independent interface, and I thought it was unrelated to cable length or material.
    If no, I believe there is another cause or solution somewhere.
    What is the main cause of the XGMII error?

    Additional information:
    MAC I/F: RGMII
    Speed: 1000BASE Target by Auto-negotiation
    Auto-negotiation: Enable

  • 0 in reply to Atsushi Takahashi
    TI__Genius 12331 points

    Hi Takahashi-san, 

    Atsushi Takahashi said:

    You said:
    What does unstable connection mean for Unit C?

    The link keeps going up and down and the link status is unstable.

    Makes sense. 

    Atsushi Takahashi said:

    You said:
    Lastly, what was the register read of 0015h?

    After which process does this indicate an action?
    After 3.1? After 3.2?

    After both scripts would be fine. I am unsure if unit C would give any meaningful results, but for unit A it would still be useful to see if the PHY is seeing any receive error. 


    Atsushi Takahashi said:

    You said:
    If not, I suggest changing 0053 2054 to writing 2053h to register 53h.

    I understand this is a 3.1 action.
    What is the difference between 2054h and 2053h?

    This changes the minimum required IPG for the PHY. 2053 is the minimum setting the PHY can tolerate. 


    Atsushi Takahashi said:
    Is the XGMII error indication related to 3.1 and 3.2?
    As the name suggests, I understand that MII is a media independent interface, and I thought it was unrelated to cable length or material.
    If no, I believe there is another cause or solution somewhere.
    What is the main cause of the XGMII error?

    I am currently unsure. There has been cases in which the XGMII error goes high when the link is dropped so it could be related to that. We will understand the meaning of this error once we get more information. 

    Best,
    J