• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 872 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: EPHY schematics review

nakashima.bo
Prodigy 30 points
Part Number: DP83825I
Other Parts Discussed in Thread: SK-AM62,

Hello Experts,

We have designed EPHY circuit with DP83825IRMQR on our PCB.
But, when Ethernet cable connects from this PCB to PC for the test, link up can be done (100Mbps, Full-duplex) but ping cannot succeed.
 
Parts name of PHY and MCU are the followings.
  PHY: DP83825IRMQR  x2 (eth0, eth1) used as RMII master mode
  MCU: AM6231ASGGGAALW

We have designed the MCU firmware of Ethernet communication module based on the one for SK-AM62.
(Changed only some parameters and defines from for RGMII mode to for RMII mode.)
We have already confirmed that the port mode select of both eth0/eth1 on MCU is RMII.

Details of ping NG;
  PC --> PCB: PC send ARP request to PCB(as global packet), but PCB send no response message to PC.
  PCB --> PC: PCB send ARP request to PC(as global packet), then PC send the response message to PCB, but then PCB send ARP request to PC(as global packet) again. It repeats until ping command of PCB is stopped.

I had asked about this issue to MCU experts on the following thread.
This new thread is to ask about it to EPHY experts followed by the advice of MCU experts.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269687/am623-cannot-establish-ethernet-rmii-data-communication-tx-rx-between-mac-and-phy/4833929#4833929

The attached PDF file is the Ethernet circuit between MCU and PHY and around PHY from the circuits of our PCB.
Please review it, and please give us some advice if it can be guessed something suspicious by the above information, or if there are what we need to check more.


Thanks,

Yasuhiro Nakashima

EthernetCircuit20230914.pdf

  • 0
    TI__Mastermind 23102 points

    Hi Nakashima-san,

    The device is currently strapped into RMII master mode, but the clock input on XI (50MHz) should only be used for RMII slave mode.

    This cannot be changed via register access, so I recommend populating the 2.49k PUs on RX_D1 (R15, R16) and removing the PDs (R17, R18) to strap the devices into RMII slave mode.

    If this does not resolve the issue, please share a register dump and re-open this thread.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 30 points

    Hello Evan-san,

    Thanks for your comment and suggestion.

    Evan Mayhew said:

    The device is currently strapped into RMII master mode, but the clock input on XI (50MHz) should only be used for RMII slave mode.

    This cannot be changed via register access, so I recommend populating the 2.49k PUs on RX_D1 (R15, R16) and removing the PDs (R17, R18) to strap the devices into RMII slave mode.

    On our PCB circuit, X2 (ECS-2520MV-250-CN-TR) is a 25MHz output Oscillator and a 25MHz clock signal "CPSW_RMII_CLK" is input to XI.
    This design is based on the information for RMII master mode shown on DP83825I datasheet, so I cannot understand why you have suggested this solution.

    I guessed a bit that your explanation means that XI doesn't work on RMII master mode setting, that is DP83825I may work on only RMII slave mode even though many specs for RMII master mode is written in the datasheet.
    So I changed RX_D1 of DP83825I from pull-down (RMII master setting) to pull-up (RMII slave setting) then confirmed the Ethernet connection, following to your suggestion, but it didn't even link-up as my prediction.

    The attached files are register dump logs of two PHYs(eth0;IC2, eth1;IC3) before/after Ethernet connection link-up, after RX_D1 is changed back to pull-down (RMII master setting).
    Please confirm these files, and investigate about causes of this issue again.

    Thanks,
    Nakashima

    regidump_eth0.txt
    regidump_eth1.txt

  • 0 in reply to nakashima.bo
    TI__Mastermind 23102 points

    Hi Nakashima-san,

    Thank you for clarifying, originally I did not see the 25MHz oscillator in the schematic shared.

    If a 25M oscillator is being used, then the original straps for RMII master mode are acceptable.

    Please use phytool rather than ethtool for generating the register dump - the values shared are not valid.

    This FAQ has details on the use of phytool:

    https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1164499/faq-how-to-read-and-write-ethernet-phy-registers-using-a-linux-terminal

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 30 points

    Morning Evan-san,

    Thanks for your reply.

    I tried to take register dump logs of two PHYs(eth0;IC2, eth1;IC3) before/after Ethernet connection link-up using phytool command.
    Please confirm them.

    I am uncertain just a little that the attached logs are with what you want, because this was the first time for me to use phytool command...

    Thanks,
    Nakashima

    regidump(phytool)_eth0.txt
    regidump(phytool)_eth1.txt

  • 0 in reply to nakashima.bo
    TI__Mastermind 23102 points

    Hi Nakashima-san,

    Thank you for sharing the register dumps, the logs are a valid reference.

    Reviewing the register dumps, the PHY's configuration and status is as expected for both the link down and link up cases.

    This leads me to think the issue is likely with the SoC software configuration.

    If you would like more confidence that the issue is not on the PHY level, one test is to send data from the SoC through the PHY and its link partner with the link partner configured in reverse loopback mode to route the same data back to the SoC:

    SoC -> PHY1 -> PHY2 (reverse loopback) -> PHY1 -> SoC

    Reverse loopback is enabled by writing 0x16[4] = 1.

    If the SoC receives the same packets, then the signal path is valid.

    Thanks,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 30 points

    Dear Evan-san,

    Thanks for your comment.

    I tried to do the loopback test with connecting between eth0 port and eth1 port, following as you explained, but the result was that both eth0 and eth1 received no packet.
    Please see the attached log.

    Evan Mayhew said:

    Reviewing the register dumps, the PHY's configuration and status is as expected for both the link down and link up cases.

    This leads me to think the issue is likely with the SoC software configuration.

    I created this thread by the suggestion from SoC expert, who considers that the causes of this issue may be on SoC side but on PHY side by his investigations.
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269687/am623-cannot-establish-ethernet-rmii-data-communication-tx-rx-between-mac-and-phy/4833929#4833929
    The above thread was closed today, but by your comment, should I ask to investigate about this issue to SoC experts again???

    Cannot I ask you to discuss about this issue between you (PHY experts) and SoC experts one time, with much information and many results which I have attached on the thread until now?

    Thanks,
    Nakashima

    LoopbackTest-log231003.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-g3983bffabc (Dec 14 2022 - 11:53:21 +0000)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.5.3--v08.05.03 (Chill Capybar')
    SPL initial stack usage: 13424 bytes
    Trying to boot from MMC2
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Loading Environment from MMC... *** Warning - No MMC card found, using default environment
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.8(release):v2.8-226-g2fcd408bb3-dirty
    NOTICE: BL31: Built : 05:06:58, Feb 24 2023
    U-Boot SPL 2021.01-00003-g348dcefba7-dirty (Oct 02 2023 - 16:50:55 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.5.3--v08.05.03 (Chill Capybar')
    Trying to boot from MMC2
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


  • 0 in reply to nakashima.bo
    TI__Mastermind 23102 points

    Hi Nakashima-san,

    I discussed with the team and have more information requests for debug:

    - Confirm trace length of RMII lines, and setup/hold time of TX/RX signals on MAC side

    - Probe RMII lines during ping operation and share scope shot

    - Perform tcpdump command during ping, to see packets sent vs. received

    It appears the MDI side connections are working with link up, but the MAC side may not be valid.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 30 points

    Hello Evan-san,

    Please see the followings.

    1)Trace length of RMII lines
    All trace length of eth0 is longer than eth1, so I confirmed trace length of eth0 RMII signals as followings.
      TX_D0: 31.98mm
      TX_D1: 34.22mm 
      TX_EN: 34.63mm
      RX_D0: 32.34mm
      RX_D1: 29.26mm
      CRS_DV: 35.63mm
      50 MHz Clock (PHY -> MCU): 40.13mm

    2)Setup/hold time of TX/RX signals on MAC side
    I am sorry but how do you expect me to confirm it?
    If from datasheet, the minimum values of these time are defined on AM62x datasheet.
    If by probing TX/RX line, I cannot to confirm because these lines are always low (0V) as explained on the first of the following thread.
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269687/am623-cannot-establish-ethernet-rmii-data-communication-tx-rx-between-mac-and-phy/4833929#4833929
    >>We measured the waveform of main signal lines around PHY.
    >>The waveforms of MDIO, MDC, 50MHzOut, TD_P/M, RD_P/M has the correct changes and seem no problem.
    >>But the waveforms of TX_EN, TX_D0, TX_D1, RX_D0, RX_D1, RX_ER, CRS_DV are always 0V with no change.

    3)Probe RMII lines during ping operation and share scope shot
    This is explained on the first of the above thread, please confirm.

    4)Perform tcpdump command during ping, to see packets sent vs. received
    The result of tcpdump during ping from PC to PCB (MCU) was "no packet captured". 


    Regards,
    Nakashima

  • 0 in reply to nakashima.bo
    TI__Mastermind 23102 points

    Hi Nakashima-san,

    The 50 MHz clock should be length matched more precisely to the MAC TX/RX lines - the current offset may cause issues when sampling the MAC signals relative to the clock. However, this does not seem to be the root cause of the issue you are seeing.

    The team found no issues with the current PHY-level implementation and status registers that would cause the MAC interface to fail to generate an output.

    To confirm that there is no issue on the PHY-level, I suggest testing with a packet generator/checker direct to the MDI with the 825 in reverse loopback mode to validate the MDI and internal PHY signal chain:

    If the generator receives the same data looped back, then the issue is isolated to the MAC / SoC side.

    In this case, please follow-up with the MCU team to further discuss possible causes on the SoC side.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 30 points

    Hello Evan-san,

    Thanks for your comments.

    As your suggestion, I tried to do MDI check as following procedure with the PHY in reverse loopback mode.
    1. Connect LAN cable between PC and PCB.
    2. Run ping command on PC.
    3. Check Wireshark on PC whether two same ping request packet are shown on Ethernet network cyclically.

    The result was that all ping request packet were shown cyclically as two same ones cyclically.

    By your comments, I understand PHY team can determine that the diagram around PHY is no probelem and the PHY is operating normally from the confirmation results so far, so the cause of this issue is thought to be on the SoC (MAC) side.

    Should I restart the discussion with the SoC team by posting new comment on this thread?
    This thread was already closed the other day, but will posting a new reply comment make this thread open again?
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269687/am623-cannot-establish-ethernet-rmii-data-communication-tx-rx-between-mac-and-phy/4833929#4833929

    Give us an advice, thanks.

    Nakashima

  • +1 in reply to nakashima.bo
    TI__Mastermind 23102 points

    Hi Nakashima-san,

    Thank you for confirming the reverse loopback test.

    Yes, the MCU team is in a better position to support this issue.

    Sincerely,

    Evan