• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 790 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.

DP83869HM: Link failure when sending data

Aldo Powell
Prodigy 10 points
Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869

I have designed a SOM containing a Xilinx XCZU2EG-L1SBVA484I ZYNQ Ultrascale+ device with the DP83869 for connecting to a 1Gb network.  We are using Vivado 2019.1 for developing the code for this product.  The debug port on the SOM reports that the DP83869 configures properly and the auto-negotiation renders the 1Gb/s rate.  However, when we attempt to send data the following sequence is reported.

Ethernet Link down

Start PHY autonegotiation

Waiting for PHY to complete autonegotiation.

autonegotiation complete

link speed for phy address 9: 1000

Ethernet Link up

Ethernet Link down

Start PHY autonegotiation

Waiting for PHY to complete autonegotiation.

autonegotiation complete

link speed for phy address 9: 1000

Ethernet Link up

Ethernet Link down

Start PHY autonegotiation

Waiting for PHY to complete autonegotiation.

autonegotiation complete

link speed for phy address 9: 1000

Ethernet Link up

memset 0x80000010 Ethernet Link down

Start PHY autonegotiation

Waiting for PHY to complete autonegotiation.

0x0autonegotiation complete

link speed for phy address 9: 1000

Ethernet Link up

This sequence of the link down, auto-negotiation, link up will continue until we stop sending data.  The host computer that we are connecting to has Wireshark running and never indicates that data has been received from the SOM.  Has anyone ever encountered this before?

  • 0
    TI__Mastermind 40275 points

    Hello,

    What type of cabling are you using to connect PHY to Link partner (LP), how long and what type? What is the link partner? 

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    The connector on the PCB is a Harwin G125-MH11005L1P.  We have an adapter cable that is no longer than 1 inch to a Halo HFJ11-1G01ERL jack.  This then connects to an off the shelf Etnernet cable that is less than 36 inches to a PC running Linux.

  • 0 in reply to Aldo Powell
    TI__Mastermind 40275 points

    Hello,

    Does this issue show up if you use longer cable length? 

    Does your PHY subsystem pass TX jitter compliance?

    In addition, can you please share your schematic? I would like to check that everything is okay from that standpoint.

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    I tried a longer cable and the results were the same.  Due to restrictions I cannot send you the entire schematic but I have added snapshots of the PHY and the adapter cable.  What are you referring to when you ask about the PHY subsystem TX jitter compliance?

  • 0 in reply to Aldo Powell
    TI__Mastermind 40275 points

    Hello,

    Thank you for your schematic. I will review it and get back to you. Please note that these may take up to a maximum of 5 working days, but I hope to get feedback to you sooner. 

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    TI__Mastermind 40275 points

    Hello,

    Would it be possible to widen the snapshot of your schematic to include the full scope of the PHY subsystem (external components such as RBIAS resistor, decaps, MDIO resistor, strapping)? After further analysis, I cannot complete sufficient review of schematic with what is given.

    Also, I noticed the magnetics used have center tap shorts as well as 10nF decaps. This is in violation with datasheet recommendation and we would recommend this be changed.

    When I mean TX jitter compliance, I mean IEEE compliance testing for PHY systems. The symptoms you are reporting give an indication of marginal design that once stressed (once packets are sent), cause non-functionality. The current prospects are checking jitter as well as ensuring power is adequately given and decoupled.

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    I have attached the complete sheet containing the PHY.  Please note that each LED line is connected to a 2K resistor driving the base of a NPN transistor to enable/disable the actual LED.  Could this possibly interfere with the strapping modes?

    The magnetics were selected because we used the same jack for the first prototype which contained a DP83867 and there were no problems with the Ethernet connection.  Unfortunately we had to switch devices due to availability issues.

  • 0 in reply to Aldo Powell
    TI__Mastermind 40275 points

    Hi,

    I would suggest monitoring the supply rails for any dipping whenever traffic is being sent. I also notice that your supply decoupling does not follow our recommendation, as well as the magnetic choice. I would advise adjusting the design accordingly to see if these issue resolve.

    Sincerely

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    I did resolve the issue with the link dropping by changing the configuration settings for the PHY.  More specifically we changed the RGMII transmit and RGMII receive clock delay bits in the RGMII_CTRL register.  We are now successfully sending and receiving data to the computer.