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.

DP83825I: Unable to Establish 100Mbps link with DP83825I Ethernet PHY.

Part Number: DP83825I
Other Parts Discussed in Thread: DP83825EVM

Dear TI team, 

I am looking for some guidance or debugging tips with an issue we are having bringing up the DP83825I ETH PHY module. 

Our current situation is that the DP83825I is unable to establish a link using 100Mbps speed. It can establish a link at 10Mbps with several link partners (any commercial Ethernet device we tried) or with another instance of our own design.

I will try to disclose all relevant information as we see fit. Please feel free to ask for more information if things are unclear.  

Current behaviour

  1. Using the default power up configuration (AN on, 100Mbps full duplex capability advertised) - the PHY is not able to reach a "link established" state - i.e. bits 2 and 5 in the BMSR register (0x1) are never asserted. Seems like AN never completes using this configuration. This is consistent with every link partner we tried.  
  2. When setting the advertised speed to 10Mbps by writing 0x61 to reg 0x4 on either side of the link, the link is properly established both when using AN and when forcing the speed without using AN.
  3. Disabling AN and trying to force a 100Mbps link doesn't establish a link.
  4. Using half duplex 100Mbps advertised for AN, or when disabling AN and trying to force it also doesn't yield a valid link.



Debug steps taken and findings

  1. All loopback modes are able to establish a link in both 10Mbps and 100Mbps full duplex modes - i.e., asserted bits 2,5 in the BMSR register.
  2. When using a loopbacked Ethernet cable (i.e., wires 1-3 and 2-6 soldered and a cable of length ~10CM), the "link established" indication is correctly asserted with 100Mbps speed in full duplex. i.e device can pass AN and establish a link with itself using any electrical design we tried (described below).
  3. BIST test using PRBS packet generation passes without errors using analog loopback - i.e., reg 0x16 is showing PRBS active and locked, no errors counted in reg 0x18.
  4. When connecting two identical DP83825I PHY designes (any of the designs 1-5 described below) we can validate both PHYs correctly latch the link partner's capabilities in their corresponding ALNPAR register (reg 0x5 bits 5:8). Our conclusion from this is that the capabilities are advertized and decoded correctly by both sides but the link establishment fails afterwards indicating the AN did not complete in the BMSR register at address 0x1 bit 5.

Electrical Design information and steps taken
Verified voltage levels, resistors, and tolerance values for peripheral devices with respect to the advertised specifications.
The reference clock is 25MHz provided by an external CMOS level oscillator in RMII master mode.  
We have tried 5 different electrical designs using different connection types between the RJ-45 connector and the PHY itself (attached and marked as ETH1-5 in the attached PDF):

  1. Full setup using Magnetics and chokes as indicated by the reference design we have, to the best of our understanding.  
  2. Same as 1, without the choke device.
  3. Choke only connection.
  4. Using 100nF caps  
  5. Using 33nF caps   

All described designs display the exact same behaviour.

Our Design Documentation:

2025-10-13 PHY_Test_RJ45_v1 - Schematics (Rev.3).PDF  


We also tried disabling Auto MDIX and forcing swaps (bit 5 in CR3 reg 0xB) without success.
Tried robust auto MDIX modes without success.
VOD levels - tried 50/150% values - without success.
SOR1 and SOR2 registers both show all 0s as expected. 

So far, we have not found any register configuration or electrical design change that enabled us to establish a 100Mbps link with any link partner. 
Attaching our electrical design for reference, we'd be happy for any pointers or debug advice we can try to overcome this.

Thanks in advance, 
Ran.   

  • Hi Ran,

    Thank you for the detailed explanation. If all loopback modes are working at 100M, the DUT itself should be ok. I have a few questions to get a better idea of the problem:

    1. Have you tested this design with a known-good 100M link partner and cable? The DUT seems to be ok, so I want to rule out a cable issue or link partner issue. A good example could be the DP83825EVM, which we have tested to work at 100M.

    2. Can you share a register dump when the PHY is connected to a link partner, but no link comes up? Specifically registers 0x0000 through 0x001F, the SOR registers, and the MSE register (0x0218)

    3. When you are testing loopback modes, are you only looking for the link indicator, or are you actually sending and receiving packets?

    • The link indicator alone is not enough to determine that a loopback mode is working.
    • I recommend checking that reverse loopback returns error-free packets. Section 2.5.3 of the DP83825 troubleshooting guide describes this test.
    • Essentially you transmit packets from the link partner, enable reverse loopback on the 825 DUT, and check that the packets are received error-free by the link partner.
    • If you have two DP83825s, you can enable PRBS on one and reverse loopback on the other.

    Best,

    Shane

  • Hello Shane, thank you for the quick response and for looking into this. 

    Regarding your questions:

    1. Yes, we have tried to create a link with AN enabled and AN disabled with various other devices and couldn't link with any using 100Mbps speed, including general commercial devices that are validated to work correctly. We can link using 10MBps speed with the same link partners.

    2. I'll share a reg dump tomorrow morning with the registers you requested. 

    3. Our indication for a valid connection is the values of reg 0x1 and 0x10 (and also reg 0x0 and 0x4, which are mostly written configurations) to match the values in the troubleshooting guide you shared in table 2-4. Specifically, we are looking at bits 2 and 5 in the BMSR register (0x1). 

    We have followed the sequence described in the troubleshooting guide in section 2.5.3 "Transmitting and Receiving Packets with BIST" with a link partner, which is another instance of our design, by asserting bit 4 of the BISCR register in the link partner, but we fail to pass this test. The same test passes when using a loopbacked Ethernet cable instead of a real link partner. 

    We also ran the next test sequence described in that section using analog loopback and using a loopback cable, and it passed (values match the documentation - PRBS is locked and no errors are counted). 

    Summarizing the findings, I would say that it seems the actual usage of a "real" link partner is what is causing these tests (and the link itself) to fail.

  • Adding requested information

    First test - connecting to a valid link partner, which is a commercial Ethernet switch connected to a local LAN.

    Equipment validation - A connection is properly established when using a commercial device (PC) with this switch and the same cable. 

    Dumping the Ethernet connection parameter from the PC yields the following information about the established link:

    Settings for end0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Full
    100baseT/Full
    1000baseT/Full
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes: 10baseT/Full
    100baseT/Full
    1000baseT/Full
    Advertised pause frame use: Symmetric Receive-only
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    1000baseT/Full
    Link partner advertised pause frame use: Symmetric
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 1000Mb/s
    Duplex: Full
    Auto-negotiation: on
    master-slave cfg: preferred slave
    master-slave status: slave
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: external
    MDI-X: Unknown
    Supports Wake-on: ug
    Wake-on: d
    Current message level: 0x0000003f (63)
    drv probe link timer ifdown ifup
    Link detected: yes

    A link is not established when replacing the PC with our design based on the DP83825I. 
    Register dump when connecting using the same cable and link partner with the DP83825I based design (schematic #1):

    Index Reg Value218)
    ----- ------ ------
    0 0x0000 0x3100
    1 0x0001 0x7849
    2 0x0002 0x2000
    3 0x0003 0xA140
    4 0x0004 0x01E1
    5 0x0005 0x0000
    6 0x0006 0x0006
    7 0x0007 0x2001
    8 0x0008 0x0000
    9 0x0009 0x0000
    10 0x000A 0x0100
    11 0x000B 0x0000
    12 0x000C 0x0000
    13 0x000D 0x401F
    14 0x000E 0x0000
    15 0x000F 0x0000
    16 0x0010 0x7812 toggles wioth 0x7912 and 0x3914
    17 0x0011 0x0108
    18 0x0012 0xE600
    19 0x0013 0x2800
    20 0x0014 0x0000
    21 0x0015 0x001D
    22 0x0016 0x0100
    23 0x0017 0x0065
    24 0x0018 0x0480
    25 0x0019 0x8000
    26 0x001A 0x0010
    27 0x001B 0x007D
    28 0x001C 0x05EE
    29 0x001E 0x0102
    30 0x001F 0x0000
    31 0x0025 0x0041
    32 0x0027 0x0000
    33 0x0101 0x2082
    34 0x010A 0x2040
    35 0x0123 0x051C
    36 0x0130 0x4F50
    37 0x0170 0x0C12
    38 0x0171 0xC850
    39 0x0172 0x0000
    40 0x0173 0x1304
    41 0x0174 0x0000
    42 0x0175 0x1004
    43 0x0176 0x0005
    44 0x0177 0x1E00
    45 0x0178 0x0002
    46 0x0180 0x0000
    47 0x0181 0x0000
    48 0x0182 0x0000
    49 0x0183 0x0000
    50 0x0184 0x0000
    51 0x0185 0x0000
    52 0x0186 0x0000
    53 0x0187 0x0000
    54 0x0188 0x0000
    55 0x0189 0x0000
    56 0x018A 0x0000
    57 0x0302 0x0000
    58 0x0305 0x0008
    59 0x0308 0x0002
    60 0x030B 0x0C00
    61 0x030C 0x0010
    62 0x030F 0x0464
    63 0x0311 0x01FC
    64 0x0313 0x06F8
    65 0x031C 0x1101
    66 0x031F 0xFC36
    67 0x033C 0xEC00
    68 0x033E 0x261E
    69 0x0404 0x0080
    70 0x040D 0x0000
    71 0x0416 0x0830
    72 0x0429 0x0000
    73 0x0456 0x0008
    74 0x0460 0x0515
    75 0x0461 0x0010
    76 0x0467 0x0533 SOR1
    77 0x0468 0x1290 SOR2
    78 0x0469 0x0044
    79 0x04A0 0x1081
    80 0x04A1 0x1040
    81 0x04A2 0x0000
    82 0x04A3 0x0000
    83 0x04A4 0x0000
    84 0x04CD 0x0408
    85 0x04CE 0x0012
    86 0x04CF 0x261D
    87 0x04D0 0x0302
    88 0x04D1 0x018B
    89 0x04D2 0x354A
    90 0x04D4 0x6633
    91 0x04D5 0x02F1
    92 0x04D6 0x0171
    93 0x04D7 0x0171
    94 0x1000 0x3100
    95 0x1001 0x7849
    96 0x1014 0x0000
    97 0x1016 0x0100
    98 0x203C 0x0000
    99 0x203D 0x0000

    Reg 0x218 value: 0x000B (changes slightly on each read)

    Test 2 - trying to connect with another instance of our own design as a link partner (connecting schematic #1 with #5):

    Index Reg Value
    ----- ------ ------
    0 0x0000 0x3100
    1 0x0001 0x7849
    2 0x0002 0x2000
    3 0x0003 0xA140
    4 0x0004 0x01E1
    5 0x0005 0x41E1
    6 0x0006 0x0007
    7 0x0007 0x2001
    8 0x0008 0x0000
    9 0x0009 0x0000
    10 0x000A 0x0100
    11 0x000B 0x0000
    12 0x000C 0x0000
    13 0x000D 0x401F
    14 0x000E 0x0000
    15 0x000F 0x0000
    16 0x0010 0x1002 Toggles with 0x5102 and 0x1104
    17 0x0011 0x0108
    18 0x0012 0x4000
    19 0x0013 0x6800
    20 0x0014 0x0000
    21 0x0015 0x0000
    22 0x0016 0x0100
    23 0x0017 0x0061
    24 0x0018 0x0480
    25 0x0019 0x8000
    26 0x001A 0x0010
    27 0x001B 0x007D
    28 0x001C 0x05EE
    29 0x001E 0x0102
    30 0x001F 0x0000
    31 0x0025 0x0041
    32 0x0027 0x0000
    33 0x0101 0x2082
    34 0x010A 0x2040
    35 0x0123 0x051C
    36 0x0130 0x4F50
    37 0x0170 0x0C12
    38 0x0171 0xC850
    39 0x0172 0x0000
    40 0x0173 0x1304
    41 0x0174 0x0000
    42 0x0175 0x1004
    43 0x0176 0x0005
    44 0x0177 0x1E00
    45 0x0178 0x0002
    46 0x0180 0x0000
    47 0x0181 0x0000
    48 0x0182 0x0000
    49 0x0183 0x0000
    50 0x0184 0x0000
    51 0x0185 0x0000
    52 0x0186 0x0000
    53 0x0187 0x0000
    54 0x0188 0x0000
    55 0x0189 0x0000
    56 0x018A 0x0000
    57 0x0302 0x0000
    58 0x0305 0x0008
    59 0x0308 0x0002
    60 0x030B 0x0C00
    61 0x030C 0x0010
    62 0x030F 0x0464
    63 0x0311 0x01FC
    64 0x0313 0x06F8
    65 0x031C 0x1101
    66 0x031F 0xFC36
    67 0x033C 0xFC00
    68 0x033E 0x261E
    69 0x0404 0x0080
    70 0x040D 0x0000
    71 0x0416 0x0830
    72 0x0429 0x0000
    73 0x0456 0x0008
    74 0x0460 0x0515
    75 0x0461 0x0010
    76 0x0467 0x0533 SOR1
    77 0x0468 0x1290 SOR2
    78 0x0469 0x0044
    79 0x04A0 0x1081
    80 0x04A1 0x1000
    81 0x04A2 0x0000
    82 0x04A3 0x0000
    83 0x04A4 0x0000
    84 0x04CD 0x0408
    85 0x04CE 0x0012
    86 0x04CF 0x261D
    87 0x04D0 0x0302
    88 0x04D1 0x018B
    89 0x04D2 0x354A
    90 0x04D4 0x6633
    91 0x04D5 0x02F1
    92 0x04D6 0x0171
    93 0x04D7 0x0171
    94 0x1000 0x3100
    95 0x1001 0x7849
    96 0x1014 0x0000
    97 0x1016 0x0100
    98 0x203C 0x0000
    99 0x203D 0x0000

    Reg 0x218 value: 0x000E (changes slightly between reads)

    One observation that came to mind looking at these results is the difference in the value of register 0x5 (ALNPAR) between the two tests - when connecting to the commercial-grade link partner, there is no latching of any capabilities in this register. When connecting to another instance of the DP83825I based design, these seem to be latched correctly. 

    Thanks again for the help, 

    Ran. 

  • Hi Ran,

    I agree that the presence of a real link partner seems to be causing the problem. If the reverse loopback fails with a link partner, it suggests there is an issue on the MDI side of the PHY. A passing result with the loopback cable and the behavior of ALNPAR are interesting. Let me take a look at these register dumps and see if there are any other leads that can be used.

    Best,

    Shane

  • Hello Ran,

    I will be supporting this debug moving forward. I see that during the bad case (PHY connected with another LP), they are unable to get the advertisements from that device (Reg 0x5). This indicates that the link partner may not be negotiating properly as the PHY is able to link up with itself. Can you please check two scenarios:

    - Is the link partner able to link up with another instance of itself?

    - Is the DP83825 able to link up with another instance of itself?

    This would remove the self-link up dependency.

    Sincerely,

    Gerome

  • Hello Gerome, and thanks for the help. 
    The link partners we are using to connect with are commercial devices (PC/router/switch). So it should work properly - these connect with each other without any issue. 

    Our DP83825 design was not able to link up with another instance of itself - the only way to have a link indication is using a loopbacked Ethernet cable (i.e., single instance loopbacked into itself)

    We have replaced the clock input circuit with a different one due to a comment we noticed in some other thread complaining about the same issue, and this seems to have solved our issue as well. 

    This is the other thread we found which complained about the same issue:
    DP83822IF: Works at 10Mbps but not at 100Mbps 


    Thanks again, 
    Ran.