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.

DP83867E: SGMII PHY not always detected after reboot (Zynq + Linux)

Part Number: DP83867E

Tool/software:

Hello,

We are using the TI DP83867E PHY in SGMII mode. The PHY is implemented on an FMC board and interfaces with a Xilinx Zynq FPGA running embedded Linux.

We are experiencing an intermittent issue: the PHY is only detected by Linux approximately 9 times out of 10 after a reboot, whether or not power is fully cycled. When the issue occurs, the MDIO interface is not accessible, and the PHY appears completely unresponsive.

The reset signal is released well after all power rails are stable. The power rails are as follows:

  • VDDIO: 3.3V

  • VDDA2P5: 2.5V

  • VDDA1P0: 1.0V

  • VDDA1P8: not used

We have reviewed the datasheet and found no specific constraints related to power sequencing. Once the PHY is properly detected, the SGMII link is stable and performs well.

Any insights or suggestions would be greatly appreciated.

Thank you!
Sébastien

  • Hello again,

    Following up on my previous post regarding the intermittent issue with the DP83867E in SGMII mode, I would like to share some additional observations based on our debugging.

    When the PHY is in the non-working (KO) state, we observe the following:

    • MDIO is functional: The MAC address is correctly retrieved and visible from Linux. For example, the output of ip a shows:

      4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
          link/ether 00:0a:35:00:01:23 brd ff:ff:ff:ff:ff:ff

      However, no physical link is detected on the interface:

    • The PHY does not detect any valid signal on the physical layer. Possible causes could be: no cable plugged, a defective cable, or an inactive switch port.

    We’ve confirmed that the cable and switch are functional in normal cases

    Any insight into potential causes (e.g., link detection logic, PHY auto-negotiation behavior in SGMII mode, known errata) would be very helpful.

    Thanks again for your support!

  • Hi Sébastien,

    However, no physical link is detected on the interface:

    Does this mean the PHY does not detect the link when the cable is plugged in? Like the LED is not on when the cable is plugged in? Or, does this mean the Linux does not detect the link?

    Since MDIO is functional, could you provide register dump (0x00 to 0x1F + 0x31 + 0x37) when the ethernet cable is plugged in?

    In addition, have you looked at this document

    Please let me know. 

    Best,
    J

  • Hello thanks J for you answer. I really appreciate this.

    PHY LEDs (Link/Activity) are always ON, regardless of link status. This occurs even when Linux reports NO-CARRIER.
    However, when the link is functional, the LEDs turn off if we unplug the cables.

    Here are some registers dumps

    Link up :
      reg 0x00 -> 0x1140
      reg 0x01 -> 0x796d
      reg 0x02 -> 0x2000
      reg 0x03 -> 0xa231
      reg 0x04 -> 0x01e1
      reg 0x05 -> 0xc5e1
      reg 0x06 -> 0x006f
      reg 0x07 -> 0x2001
      reg 0x08 -> 0x6801
      reg 0x09 -> 0x0300
     
    Link Fail : 
      reg 0x00 -> 0x1140
      reg 0x01 -> 0x796d
      reg 0x02 -> 0x2000
      reg 0x03 -> 0xa231
      reg 0x04 -> 0x01e1
      reg 0x05 -> 0xc5e1
      reg 0x06 -> 0x006d
      reg 0x07 -> 0x2001
      reg 0x08 -> 0x6801
      reg 0x09 -> 0x0300

    I need to perform extra tests to complete with the missing values. I expect to do this on monday. 

    Meanwhile I'll check the document.

    Regards,

    Sébastien

  • Hi Sébastien, 

    Based on your description, it could be either the PHY or the RJ45 connector is bad. Would you be able to perform ABA swap on the PHY and the RJ45 connector and see if the issue disappears?

    Best,
    J

  • Hello, Thanks for your inputs.

    We don't have the full view over the registers but here is what I can give so far:

    reg 0x00 -> 0x0140
    reg 0x01 -> 0x7949
    reg 0x02 -> 0x2000
    reg 0x03 -> 0xa231
    reg 0x04 -> 0x01e1
    reg 0x05 -> 0x0000
    reg 0x06 -> 0x0064
    reg 0x07 -> 0x2001
    reg 0x08 -> 0x0000
    reg 0x09 -> 0x1300
    reg 0x0a -> 0x0000
    reg 0x0b -> 0x0000
    reg 0x0c -> 0x0000
    reg 0x0d -> 0x0000
    reg 0x0e -> 0x0000
    reg 0x0f -> 0x3000
    reg 0x10 -> 0x5c48
    reg 0x11 -> 0xa802
    reg 0x12 -> 0x0000
    reg 0x13 -> 0x0040
    reg 0x14 -> 0x29c7
    reg 0x15 -> 0x0000
    reg 0x16 -> 0x0000
    reg 0x17 -> 0x0040
    reg 0x18 -> 0x6150
    reg 0x19 -> 0x4444
    reg 0x1a -> 0x0002
    reg 0x1b -> 0x0000
    reg 0x1c -> 0x0000
    reg 0x1d -> 0x0000
    reg 0x1e -> 0x0002
    reg 0x1f -> 0x0000

    Regarding your comment, we are still working on having a second board for tests. I was wondering if you are ok if I share with the interesting parts of the schematics for quick review?

    Thanks.

    Sebastien

  • Hi Sébastien,

    I would be happy to review the schematic. You can attach it on your post or you can directly send it to me via message after accepting my friend request.

    What state the PHY is in when this register dump was produced? It doesnt look like the PHY is in the problematic state. If you can, please send me the register dump when the PHY enters the unresponsive state.

    Best,

    J

  • Hello,

    Thanks for the help.

    I would rather send it through messages if you don't mind. I'll wait for your friend request. :-)

  • Hi I just sent the friend request. 

  • Hi, 
    Schematic looks good. Please see attached. Please update me on the register dump.

    Copy of DP83867_Schematic_Checklist_Commented.xlsx

    Best,
    J