• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 33 subscribers
  • Views 594 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.

Original question:

DP83TD510E: Link not establishing between two phys

DP83TD510E: No data transferred with active link shown.

Eric Dziaba
Prodigy 10 points
Part Number: DP83TD510E
Other Parts Discussed in Thread: DP83822H,

I am working with a custom board that aims to be a media converter using the DP83TD510E PHY and DP83822H PHY. The design of the custom board is mostly the same as the DP83TD510E-EVM with the main difference being both PHYs are configured as RMII slave and share the same 50Mhz Clock (25 ppm). Both PHYs show that their respective links are established, DP83TD510E shows an active twisted pair link and DP83822H shows an active Ethernet link. I am using an external MCU to read/write register data via MDIO SMI lines. The PHYs are directly connected. I have read the registers of the PHY and have verified that they are both running as RMII slave with their SOR registers reflecting the intended straps.

I am using a DP83TD510E-EVM board to test against the custom board I am working with. The active twisted pair link is shown on the EVM board as well. The issue I am having is that no data is able to pass through the setup. The same setup works when I have two EVM boards interfacing with each other. Another observation is that AN_CTRL_10BT1 and AN_STATUS_10BT1 registers on the custom board both return 0x0000 even when writing into them. Also, the PKT_STAT of the tx packets match the the count of the tx packets with CRC error. Rx packets show no errors. This is leading me to think that perhaps the issue lies with the PHY to PHY RMII communication on the custom board. If anyone has any suggestions on what to check to verify the problem, please let me know.

Any help would be appreciated.

Thanks,

Eric

  • 0
    TI__Mastermind 24998 points

    Hi Eric,

    Are the MII connections the same between both setups?

    Eric Dziaba said:
    Another observation is that AN_CTRL_10BT1 and AN_STATUS_10BT1 registers on the custom board both return 0x0000 even when writing into them.

    These registers are within the extended register space and require a specific procedure for reads/writes to take effect.

    Please refer to this FAQ for the procedure:

    https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1133146/faq-dp83tg720s-q1-how-to-read-or-write-registers-in-extended-register-space-of-ethernet-phy

    For both setups during link (510EVM <-> 510EVM and 510EVM <-> custom board), please share the following registers so I may confirm if there are any configuration differences:

    0x10, 0x12, 0x17 (MMD 1F)

    0x200. 0x20E, 0x20F (MMD 7)

    0x18F6, 0x18F7 (MMD 1)

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hey Evan,

    Thanks you for reaching out. I have read the requested registers from each setup (Setup1: 510EVM <-> 510EVM; Setup2: 510EVM <-> Custom Board). I have attached the individual results, summary of results, and the script used for reading out of the 510EVM boards. AN_CTRL_10BT1 and AN_STATUS_10BT1 register were not 0x0000 when I read it this time (however, still no data passthrough).

    Fullscreen Read-Registers-Script.txt Download 
    // Read registers 0x10, 0x12, 0x17, 0x200, 0x20E, 0x20F, 0x18F6, 0x18F7
begin
// read 0x10
000D 001F
000E 0010
000D 401F
000E
// read 0x12
000D 001F
000E 0012
000D 401F
000E // read
// read 0x17
000D 001F
000E 0017
000D 401F
000E
// read 0x200
000D 0007
000E 0200
000D 4007
000E
// read 0x20E
000D 0007
000E 020E
000D 4007
000E
// read 0x20F
000D 0007
000E 020F
000D 4007
000E
// read 0x18F6
000D 0001
000E 18F6
000D 4001
000E
// read 0x18F7
000D 0001
000E 18F7
000D 4001
000E
end

    Setup1-Setup2_Register-Results.pdf

    Fullscreen Setup1-510EVM1-Register-Results.txt Download 
    Read registers BATCH1.txt file is open...
Register 000D is: 001F

Register 000E is: 0010

Register 000D is: 401F

Register 000E is: 0001

Register 000D is: 001F

Register 000E is: 0012

Register 000D is: 401F

Register 000E is: 2000

Register 000D is: 001F

Register 000E is: 0017

Register 000D is: 401F

Register 000E is: 4021

Register 000D is: 0007

Register 000E is: 0200

Register 000D is: 4007

Register 000E is: 1000

Register 000D is: 0007

Register 000E is: 020E

Register 000D is: 4007

Register 000E is: B000

Register 000D is: 0007

Register 000E is: 020F

Register 000D is: 4007

Register 000E is: B000

Register 000D is: 0001

Register 000E is: 18F6

Register 000D is: 4001

Register 000E is: 1000

Register 000D is: 0001

Register 000E is: 18F7

Register 000D is: 4001

Register 000E is: 3001

End of file.

    Fullscreen Setup1-510EVM2-Register-Results.txt Download 
    Read registers BATCH1.txt file is open...
Register 000D is: 001F

Register 000E is: 0010

Register 000D is: 401F

Register 000E is: 0001

Register 000D is: 001F

Register 000E is: 0012

Register 000D is: 401F

Register 000E is: 2000

Register 000D is: 001F

Register 000E is: 0017

Register 000D is: 401F

Register 000E is: 4021

Register 000D is: 0007

Register 000E is: 0200

Register 000D is: 4007

Register 000E is: 1000

Register 000D is: 0007

Register 000E is: 020E

Register 000D is: 4007

Register 000E is: B000

Register 000D is: 0007

Register 000E is: 020F

Register 000D is: 4007

Register 000E is: B000

Register 000D is: 0001

Register 000E is: 18F6

Register 000D is: 4001

Register 000E is: 1000

Register 000D is: 0001

Register 000E is: 18F7

Register 000D is: 4001

Register 000E is: 3001

End of file.

    Fullscreen Setup2-510EVM-Register-Results.txt Download 
    Read registers BATCH1.txt file is open...
Register 000D is: 001F

Register 000E is: 0010

Register 000D is: 401F

Register 000E is: 0001

Register 000D is: 001F

Register 000E is: 0012

Register 000D is: 401F

Register 000E is: 2000

Register 000D is: 001F

Register 000E is: 0017

Register 000D is: 401F

Register 000E is: 4021

Register 000D is: 0007

Register 000E is: 0200

Register 000D is: 4007

Register 000E is: 1000

Register 000D is: 0007

Register 000E is: 020E

Register 000D is: 4007

Register 000E is: B000

Register 000D is: 0007

Register 000E is: 020F

Register 000D is: 4007

Register 000E is: B000

Register 000D is: 0001

Register 000E is: 18F6

Register 000D is: 4001

Register 000E is: 1000

Register 000D is: 0001

Register 000E is: 18F7

Register 000D is: 4001

Register 000E is: 3001

End of file.

    As to the questions of the RMII interface:

    As far as I can tell, the RMII connections are the same as the 510EVM with the difference being the DP83TD510E phy is not outputting a reference clock to the DP83822H phy (Both configured as RMII slave and sharing 50MHz clock on XI pins).

    RMII Connection summary:

    CustomBoard_RMII_Connections.pdf

    Thanks,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Thank you for sharing the register dumps, the configuration and pinout looks good to me.

    When you note that data does not pass through the setup, are you able to probe the MAC and MDI lines to see if / where the data activity stops at any part of the signal chain?

    Regards,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hey Evan,

    From what I see, the data activity seems to break between the custom board's DP83TD510E phy and DP83822H  phy. The reason I believe this to be the case is for the following reasons:

    When reading registers 0x12B-0x130 of the DP83TD510E phy of the 510EVM and custom board of setup 2, I compared their packet counts and have found the following:

    510EVM: The Tx packet count equaled the exact number of Tx packets with error (failed CRC). The Rx packet count had no errors.

    Custom Board: The inverse result was observed where the Rx packet count equaled the exact number of Rx packets with error (failed CRC), and the Tx packets had no errors.

    This seems to suggest that the hardware analog end of the twisted pair link is functioning. I have also probed the differential pair and they look identical to the 510EVM (setup1) from a qualitative perspective. It seems that the custom board is just attempting to transmit bad data, but received data is fine. I don't see a packet register count for the DP83822H so I can't verify the packet validity from that end. However, I did wireshark the data coming into the DP83822H phy of the custom board and traffic appeared normal.

    The MDIO lines are working fine. I am currently working on analyzing the MAC interface between the phys.

    Thanks,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    I agree that the issue appears to be on the MAC interface in this case.

    I would like to confirm the following to narrow down root causes:

    - Probe the XI pin on DP83822 and DP83TD510E to confirm they are receiving the 50M clock.

    - Share register dump for DP83822 during link so I may confirm the correct configuration relative to our 510EVM

    Please also share the schematic so I may review the pinout and strap (email to e-mayhew@ti.com for private share)

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hey Evan,

    I have sent you the schematic. Probing the XI pins showed that the 50 MHz clock was present on both phys (both in phase). There was also activity seen on the RMII RX_D0:1 and TX_D0:1 lines. Which registers in particular would you like to see from the DP83822 phy?

    Thanks,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Thanks for sharing the schematic. I see no issues with the pinout and straps.

    Please share the following DP83822 register values:

    0x0, 0x1, 0x4, 0x5, 0xA, 0x10, 0x12, 0x17, 0x467, 0x468 (no MMD procedure required, select "Yes" on Extended Register drop-down menu)

    Do you have packet generation / checking capabilities? If so, I recommend the following test to validate the MAC connection on the custom board:

    Write DP83TD510E register 0x0[14] = 1 (enable MII loopback)

    Send packets from host -> DP83822 -> DP83TD510E, and verify if host receives the same packets looped back.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hey Evan,

    Sorry for the delayed response. There were some issues with the routing on the PCB relating to some of the phy connections on the custom board. We should have a new proto coming in this week. I will let you know the result when it comes in.

    Thanks,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Thanks for the follow-up, I'm curious to know if the PCB routing issues were the root cause of the data transfer issue.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hi Evan,

    I received the new boards. There were signal integrity issues with the previous boards, and the signals are this one are much cleaner. However, data only seems to flow correctly in one direction. For example: host1 <-> custom board <-> EVM <-> host 2, host1 can see the network activity of host2. The data host2 sees from host1 is not valid.

    I have enabled the loopback on the custom board's DP83TD510E phy and have observed the same problem packets that host2 was seeing. Therefore the issue seems to still be localized on the custom board. I'm not sure if the problem is between the RMII connections between the two phys (the signals don't looks distorted by any means) or between the ethernet phy and the connector. I am currently looking into a way to loopback the packets back from the ethernet phy to see if the data is encountering the issue through the rmii interface or ethernet interface: host1 -> ethernet phy -> host1.

    Thanks,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Thanks for the update and thorough test results.

    This is my understanding of the suspect signal chain:

    Host1 <-RJ45-> DP83822 <-RMII-> DP83TD510E

    To validate the RJ45 connection, enable reverse loopback on DP83822 with 0x16[4] = '1' and verify the host receives the same data.

    To validate the RMII connection, enable MII loopback on DP83TD510E with 0x0[14] = '1' and verify the host receives the same data.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hey Evan,

    I have read the requested registers and have ran some loopback tests. Here are the results I observed: DP83822_registers.pdf

    It looks like the issue is not with the RJ45 interface based on the loopback results. I'm wondering if the issue still lies with the RMII interface.

    Thanks,

    Eric

  • +1 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Could you perform the same MII loopback test separately on the custom board and EVM? 

    If possible, please share MAC data scope captures for each test.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hi Evan,

    Yes, I will get that information. Another test I would like to run to see if it would have an affect is running the RMII at 5-MHz. One change on this new board is that the DP83TD510e has a 25-MHz crystal and is running in master mode. The clock is output to the DP83822 through the clk ref pin.

    I noticed that the DP83TD510e has a slow mode where it's output clock can be set to 5-MHz. I set this on the EVM board to test, however, it would not establish an ethernet link afterwards (probed the clock and verified it was 5-MHz). Is there any setting on the DP83822 that needs to be adjusted to compensate for this modified speed?

    Thanks,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Unfortunately DP83TD510E's RMII slow mode is not applicable in this case, as there is no setting in DP83822 to allow it to function with a 5MHz clock on XI.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 10 points

    Hey Evan,

    I have identified the issue. The culprit: TX_D0 and TX_D1 were swapped coming from the DP83TD510E PHY (can see a net mislabel on the schematic I sent you). This was discovered when I was analyzing/probing and manipulating the traces of the RMII data lines. All signals looked great with very little distortion. It turns out the issue was just a dumb mistake. I would like to thank you for all your assistance.

    Cheers,

    Eric

  • 0 in reply to Eric Dziaba
    TI__Mastermind 24998 points

    Hi Eric,

    Happy to hear you found the issue, thank you for following up for closure.

    Apologies for not catching the net label issue on the initial schematic shared.

    Best regards,

    Evan