DP83869HM: No Link w/1000BASE-KX Host Link Partner (Copper-based) in Media Converter & SGMII-to-Copper Modes - Help Requested

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869

In a previous TI forum ticket link here, a TI app engineer said that the DP83869HM should support a 1000BASE-KX linkup with a MAC host, provided both ends of the link were set to forced speed 1G mode, full duplex, etc. 

I followed this design spec per the above link app engineer's recommendations and have not been able to get a link/ping through from the 1000base-T line side to the host on the 1000Base-KX side.  The host 1000BASE-KX PHY/MAC connection is an Abaco SWE540A VPX-card ethernet switch.  The setup is the media converter system as in the block diagram example below:

image.png

The Base-T side has been verified a good link at 1G, so the main issue seems to be the fiber/SGMII side.

We have tried both 1000Base-X media converter mode (OPMODE2:0=100), and SGMII-to-Copper modes (OPMODE2:0=110), with the auto-negotiation both on and off (i.e., forced speed) on both link partners. 

We then followed the steps in the SNLA443 DP83869 Troubleshooting Guide, and all pins (RBIAS, RESET_N) and modes seem to be checking out corrrectly.  Clock is a bit noisy, but not bad.

I then measured the Rx/Tx lines on the SERDES/host side of the interface (SIP/N, SOP/N) and I have attached the eye diagram measurements (see below), which seem to meet the SGMII Eye Mask Requirements from the TI troubleshooting document (also included below).  

 

Any help in troubleshooting is appreciated.  We have working communication with the MDIO registry, so I can read/write and report back any registries requested by the TI app engineer.

Thanks,
Justin Muzzy

    

 

  • Hi Justin,

    Thank you for the thorough problem statement. I see one eye diagram in your post, however I am curious if you've measured the eye near the MAC SIP/N pins and near the PHY SIP/N pins. 

    The best place to probe high speed signals is at the input on both sides. If the signal is clean near both the PHY and the MAC we can rule out a layout issue.

    Another test you can try is to send packets from the MAC -> 869 -> to a PC connected via ethernet cable. Additionally send packets from an attached PC -> 869 -> the MAC. If the PC or MAC is able to receive packets successfully, we know the associated path is working.

    • A ping test requires both the TX and RX path to work in order to successfully ping. Failure to ping could be an issue on either the TX or RX.
    • The goal of these tests is to isolate whether there is an issue on the TX path or the RX path (or both)

    Best,

    Shane

  • Hi Shane,

    Thank you for a quick first response.   Please see below (or attached) the eye diagram and measurements from the SIP/N input pins near the DP83869HM PHY IC, coming from the host MAC/PHY (ABACO switch card).  It is lower in signal quality than the previous output of the TI- PHY which is expected given the trace distance, but appears to still be within the SGMII spec.

    Unfortunately, I am unable to probe for proper eye diagram measurements near the input of the host MAC/PHY due to inaccessibility.  The switch card is plugged into a VPX backplane and there is simply no access to the PCB within the card, especially while plugged in and operating.  Given that the SIP/N eye diagram looked decent into the 869, I'm thinking it's likely the opposing traces into the host MAC have similar characteristics.

    Regarding your suggestion for one-way packet sending - is there a process/procedure detailed in a TI document for this, including what registries to r/w to observe any data flow?  I'm not familiar with a 'one-way' ping/packet command from a PC.  I will have to ask the MAC manufacturer if there are built-in commands for one-way packet transmission.  

    Are there any other registries of note or things to try that might give a clue to the issue?

    Regards,
    Justin

  • Hi Justin,

    I agree the signal should still be legible even though it appears under-equalized. For one-way packet transfer it would be good to check with the manufacturer if your MAC can do this. Additionally, section 1.4.2 of the SGMII troubleshooting guide may help here. If the MAC can send out packets and the attached PC can receive them, we know the transmit path is working. On the attached PC, a network monitoring tool like wireshark can be used to see incoming packets.

    Some other ideas I have that can help us figure out where the issue is:

    1. When you ping through the connection is the destination host entirely unreachable, or is there only packet loss?

    2. Can you monitor register 0x0015 while pinging through the connection to check for receive errors? If you see this register value increasing, there is a problem with the MDI Copper connection (not 1000Base-KX). Even though the PHY may link up on the copper MDI, a poor connection can still cause packet loss/errors.

    3. If the MAC can output packets one-way, you can perform an SGMII loopback test. MII loopback takes packets received from the SGMII pins and loops them back on the SGMII outputs. The MAC should receive these packets back if the 1000Base-KX connection is working. 

    4. In SGMII mode do you notice the SGMII_PAGE_RX register going high?

    Best,

    Shane

  • Hi Shane, please don't close this ticket out yet.  I'm waiting for available test time on the chassis and hope to have answers within a day or two.  Thanks, Justin.

  • Also, does the SGMII status register you refer to above apply in our situation, where the host MAC is only advertising 1000Base-KX and technically not SGMII?

  • Hi Justin,

    Thanks for the update, I'll keep this ticket open and look out for your next response Slight smile

    Also, does the SGMII status register you refer to above apply in our situation, where the host MAC is only advertising 1000Base-KX and technically not SGMII?

    Since you're in SGMII mode I figured we could check this to see whether configuration data is passed between the PHY and MAC. You may be right that this would only apply in SGMII communication.

    When you test, try both SGMII and media converter mode. In media converter mode be sure the signal detect (SD) pin is disabled or forced to a 'detect' state otherwise the fiber interface will not register a connection. If you can try/answer the other 3 questions in my last response it may help narrow down the issue.