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.

Linux/DP83867IS: PHY appears to enter POWER DOWN unprovoked

Part Number: DP83867IS

Tool/software: Linux

We are having stability issues with the DP83867IS in our design. This has worked well on ~60 prototypes until we introduced a new Ethernet switch to interface our boards. This switch is the Planet FSD-803. After introducing this switch, I am seeing roughly 2% packet loss on the designs using DP83867IS (where we prevously have seen none), but no other products using this switch appears to be affected.

The worst thing is that between 2 minutes and a couple of days, the isue gets worse and we permanently loose link to our design. The ONLY way out is to powercycle the design, pulling the physical reset pin low is not enough to clear the issue.

Measuring on the MDIO interface, it seems the DP83867IS has entered POWER DOWN although our SW should not touch the physical PWDNn or write to this bit (the physical signal is also pulled high by 2k2).

I don't see MDIO transactions regularly like I see when Ethernet is working, but when I do ifdown->ifup I see the following two transactions:

First:

ST=01

TA=10 (Write)

PHYADD=01111

REGADR=00000

TA=10

DATA=0000-0001-1110-0001

Second:

ST=01

OP=01 (Read)

PHYADD=01111

REGADR=00000

TA=10

DATA=0000-1001-1110-0001

Any help moving forward with this issue would be greatly appreciated!

  • Hi,

    Kindly share following information:

    1. HW Configuration you have set using straps.

    2. Can you measure the power when you think DP83867 is in low power state ?

    3. List of register configuration you are performing on DP83867 thru MDIO.

    4. schematics

    Regards,

    Geet

  • Eth0PHY.pdfHello, and thank you for the quick reply.

    1:  Apart from 2k49 pull-ups on RX_D0 and RX_D2 (for PHYADD 15), all are left open - but we have had issues during boot when the attached SoC has implemented internal 25k pull-up on some of these pins during boot-up. This is why we are pulling the physical reset pin of the PHY when the SoC is fully configured, so we should not interfere with the strap configuration when the PHY reads these after reset. The strap configuration is listed in the attached schematics.

    2: We have not been able to measure any difference in power when the PHY appears to enter power down. The design is working off a 24V supply, current consumption was 0.17A before and during failure.

    3: Register configuration, we should be setting the following via our DTS:

    ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>; >>> register 0x0086

    ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>; >>> register 0x0086

    ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; >>> register 0x0010

    We have tested with linux kernel version 4.12 and 4.15 from Rocketboards, where we use /drivers/net/phy/dp83867.

    4: Schematics attached.

    5: We have also listed some mii diagnostics before and during failure, but we don't yet know how much we trust the results in run during failure. The results are in the attached text file.

    mii_diag.txt
    ----------Before failure, with ~2% packet loss---------------
    # mii-diag -v
    mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
     http://www.scyld.com/diag/index.html
    Using the default interface 'eth0'.
      Using the new SIOCGMIIPHY value on PHY 15 (BMCR 0x1140).
     The autonegotiated capability is 01e0.
    The autonegotiated media type is 100baseTx-FD.
     Basic mode control register 0x1140: Auto-negotiation enabled.
     You have link beat, and everything is working OK.
       This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
       Able to perform Auto-negotiation, negotiation complete.
     Your link partner advertised cde1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
       End of basic transceiver information.
    
    libmii.c:v2.11 2/28/2005  Donald Becker (becker@scyld.com)
     http://www.scyld.com/diag/index.html
     MII PHY #15 transceiver registers:
       1140 796d 2000 a231 01e1 cde1 006d 2001
       6001 0300 0000 0000 0000 4003 0400 3000
       5048 7c02 0000 1e42 29c7 0000 0000 0040
       6150 4444 0002 0000 0000 0000 0002 0000.
     Basic mode control register 0x1140: Auto-negotiation enabled.
     Basic mode status register 0x796d ... 796d.
       Link status: established.
       Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
       Able to perform Auto-negotiation, negotiation complete.
     Vendor ID is 08:00:28:--:--:--, model 35 rev. 1.
       No specific information is known about this transceiver type.
     I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
       Advertising no additional info pages.
       IEEE 802.3 CSMA/CD protocol.
     Link partner capability is cde1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
       Negotiation  completed.
       
    ----------During failure, with no link---------------
    # mii-diag -v
    mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
     http://www.scyld.com/diag/index.html
    Using the default interface 'eth0'.
      Using the new SIOCGMIIPHY value on PHY 15 (BMCR 0x01e1).
     Basic mode control register 0x01e1: Auto-negotiation disabled, with
     Speed fixed at 10 mbps, full-duplex.
      Internal Collision-Test enabled!
     Basic mode status register 0x01e1 ... 01e1.
       Link status: not established.
       This transceiver is capable of <Warning! No media capabilities>.
       Unable to perform Auto-negotiation, negotiation complete.
     Your link partner is generating 100baseTx link beat  (no autonegotiation).
       End of basic transceiver information.
    
    libmii.c:v2.11 2/28/2005  Donald Becker (becker@scyld.com)
     http://www.scyld.com/diag/index.html
     MII PHY #15 transceiver registers:
       01e1 01e1 01e1 01e1 01e1 01e1 01e1 01e1
       01e1 01e1 01e1 01e1 01e1 4007 01e1 01e1
       01e1 01e1 01e1 01e1 01e1 01e1 01e1 01e1
       01e1 01e1 01e1 01e1 01e1 01e1 01e1 01e1.
     Basic mode control register 0x01e1: Auto-negotiation disabled!
       Speed fixed at 10 mbps, full-duplex.
      Internal Collision-Test enabled!
     Basic mode status register 0x01e1 ... 01e1.
       Link status: not established.
       Capable of <Warning! No media capabilities>.
       Unable to perform Auto-negotiation, negotiation complete.
     This transceiver has no vendor identification.
     I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
       Advertising no additional info pages.
       IEEE 802.3 CSMA/CD protocol.
     Link partner capability is 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
       Negotiation did not complete.
    #

  • There has been some developments in this case. In order to focus on one problem at a time, I had not yet mentioned that we also observed failed auto negotiation with some GbE Ethernet devices. We found a fix related to the RX_DV/RX_CTRL pin strapped in mode 1 or 2 (see attached word document for more information and some questions we would like clarification on).

    This solved auto negotiation with GbE devices, and it seems to have had an effect on the instability that appears to cause POWER DOWN. With the new fix, the DP83867 fails auto negotiation with the "unstable" 100Mbit switch - but if we disable GbE advertisement we get 100% stable 100Mbit link and communication.

    I hope you will be able to answer the questions in the attached document, we would like to understand what the root cause of this issue is.

    In final, we have implemented support for TDR using this PHY. Can we use the calculation for "cable length and fault location" described for DP83822? Based on our tests, we seem to get a value that is 7-10m too high - what kind of accuracy should we expect from this measurement?

    GBitIssue.docx

    Regards,

    Thomas

    RX_DV/RX_CTRL pin strapped in

                                        mode 1 or 2

  • Hi Thomas,

    If not strapping for mode 3 on RX_CTRL then you do need to clear bit[7] in register 0x31 like you mentioned.
    Please follow that with a soft reset by writing 0x4000 to register 0x1F.
    The DP83867IS has a hidden bootstrap that is not functional. If you do not strap to mode 3, the PHY can have issue with certain link partners. If you cannot strap to mode 3, bit[7] in register 0x31 is another work-around.

    RX/TX delay and FIFO depth are dependent on you system. You will need to see what the internal delay of your MAC is and also account for any trace delay. After doing that you can pick the type of delay that gives you the most margin for setup/hold. FIFO depth is dependent on your expected frame size.

    When you see the unstable link issue occurring with the 100Mbps switch, do you see the signaling on the MDI changing for the DP83867IS? Can you probe the MDI both RD and TD pins to see how the signaling looks? Are you writing bit[7] in register 0x31 before establishing link with the connected switch?
    If you experience the issue and then disconnect the cable, does the PHY recover? Do the registers always read 0x01E1?

    Can you check the clock being supplied to the DP83867IS when the issue occurs?
  • Hello Ross,

    We have now also implemented the soft reset after clearing bit[7] in register 0x31. After doing this, we have not been able to provoke the unstable state or power down state that we reported earlier.

    I have not measured the MDI when the instability was present, only when the instability ended up in the permanent "power down" mode. Once the PHY enters this mode, removing the cable and connecting to anything else does not change anything, and we were unable to reestablish autoneg or link by trying to change PHY settings - registers keep reading 0x01E1. When this was occuring, we were not clearing bli[7].

    RD and TD pins of MDI, I'm not sure I understand. We have MDC and MDIO, I've been probing MDIO both TX and RX timeslots, but connecting a probe to MDC has not been possible due to the compact design.

    Regards,
    Thomas
  • Hi Thomas,

    It appears then that the issue you were experiencing was a result of the invalid strap state.
    Please either have the strap state be MODE 3 or use bit[7] in register 0x31 as part of your initialization.
  • Hello Ross,

    Yes, things are a lot more stable now. Thank you for the support!

    Regards,
    Thomas