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.

AM263P4: Ethernet / CPSW Link Troubleshooting

Part Number: AM263P4
Other Parts Discussed in Thread: DP83826E, SYSCONFIG

Tool/software:

I am trying to bring-up CPSW with a DP83826E on a custom PCB.

So far, I have been able to bind a driver, but I have not been able to successfully establish Link Status.

The CPSW driver is configuring the PHY, and then entering FSM state ENETPHY_FSM_STATE_NWAY_WAIT.

This eventually results in EnetPhy_phyTimeout() and FSM state ENETPHY_FSM_STATE_FOUND. The process configuration, and Auto Negotiation wait then repeats.

 

I added some DebugP_log() printfs to aid troubleshooting. These print BMCR,BMSR: registers from within enetphy.c. These printfs are in hexadecimal, and can be seen here:

 

[Cortex_R5_1] ==========================

  CPSW LWIP TCP CLIENT   

==========================

u32IdRead:10,10,0

Starting lwIP.Enet IF UP Event. Local interface IP:192.168.1.253

Waiting for network UP ...

BMCR,BMSR:3100,7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

Waiting for network UP ...

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

BMSR:7849

 

 

Note: The print:

u32IdRead:10,10,0

means the PHYIDR1, PHYIDR2 registers have been successfully read 10 times, and each time the values matched what is specified in the DP83826 datasheet.

 

I have tried linking with link partners:

  TL-SG105 – simple switch

  Windows PC - computer

Both link partners have been used successfully for numerous other Ethernet tests. I also tried swapping Cat6 Ethernet cables. These cables also are ‘known good’.

 

 

For reference, I decoded the BMCR and  BMSR registers.

 

This is the debug view when halted at EnetPhy_nwayStartState() :

 

Q1a:

Am I missing something in the PHY configuration?

 

Q1b:

Are there any other registers that would be useful to analyze?

 

Q2:

I am considering adding Loopback test functionality to my project. Do you think an analog loopback would be an efficient way to troubleshoot?

 

Q3:

I am considering probing on MDI to see if there is Autonegotiation occurring. My scope may not be able to decode the signals TD+ TD- RD+ RD- signals, but I believe I should be able to detect if there are transmissions occurring.

Is probing MDI useful for troubleshooting?

 

Q4:

Can you recommend any other troubleshooting measures not mentioned here?

  • Hi Tollman,

    Appreciate such a detailed query. I will go through the issue and loop in the folks who can help with this.

    Regards,
    Shaunak

  • Hi Tollman,

    1ab) I don't see any issues with the PHY config. The configs expected for MDI link (auto-neg, full duplex, loopback off) are correct.

    2) If you are able to check what data is received on the processor side, then analog loopback would be useful to validate the on-board signal path between PHY<->MAC. However, I don't expect this to uncover root cause for MDI link failure.

    3) Probing MDI link would be useful to verify auto-negotiation pulses are occurring on the line. If there are doubts about MDI terminations, then verifying proper signal levels here would also be useful.

    With valid register access and auto-negotiation failing, I suspect the issue is with the MDI circuit or link partner ability.

    Please share the schematic and confirm the link partner has auto-negotiation enabled (can email to e-mayhew@ti.com for private share).

    Thank you,

    Evan

  •  1)

    Regarding PHY config. Thanks for the analysis. Issue closed.

     

    2)

    Regarding analog lookback. I may look into integrating the SDK example based on the feedback for item 3).

    If I go with this approach, I think I would need a device like this:

      Amazon.com: Networx® CAT6 Gigabit RJ45 Loopback Tester : Everything Else

    Is this correct?

      

    3)

    Regarding probing MDI. I decided to start by tapping on my ethernet cable, and probing TX and RX. By disconnecting and reconnecting the cable between the custom (Sitara) PCB, and the switch, I can compare the behavior.

    On the other side of the cable is a:

       TL-SG105 | 5-Port 10/100/1000Mbps Desktop Switch | TP-Link

    This is a very popular (>100k Amazon reviews) ‘dumb’ layer 2 switch.  5× 10/100/1000Mbps RJ45 Ports supporting Auto Negotiation and Auto MDI/MDIX.

    In preparation, I read into the page:

    Autonegotiation - Wikipedia

     

    Test 1:

    With the cable is connected only to the Sitara PCB, I see no activity on either ‘signal pair’.

     

    Test 2:

    The cable is connected on both ends I see pulses and what are probably Autonegotiation pages on both ‘signal pairs’.

     

    Test 3:

    The cable is connected on only the switch end, I see the same activity as with Test 2. I think the switch is attempting Autonegotiation on both ‘signal pairs’ since the link partner may be half-duplex.

     

    I think this suggests an issue between the MDI of the PHY, and the RJ-45.

    Do you agree?

     

     4) 

    I think it makes sense to review the schematic and layout again. I may do this through my FAE.

    Regards,

    Tollman.

  • Hi Tollman,

    Appreciate the detailed response and queries.

    Q2) Analog loopback returns the data to the MAC, without transmission to the PHY's MDI output:

    Analog loopback test does not require external RJ-45 loopback, as this is only verifying signal chain between MAC<->PHY.

    If you would like to validate the MDI side connection, reverse loopback mode and external loopback tester are both valid options.

    For reverse loopback, the setup would be:

    PHY1 <-> RJ45 <-> PHY2 <-> MAC

    - Enable reverse loopback on PHY1 

    - Send data from MAC2 -> PHY2 -> PHY1

    - Verify this data is looped back to PHY2 without error

    Q3) Thanks for confirming. This switch seems compatible, so I suspect the issue is on the hardware-level with the MDI scheme or layout. 

    Just to cover all possible causes, please verify:

    - What is the MAC interface being used (MII/RMII)?

    - If in RMII mode, is master/slave mode being used, and what is the input clock on XI to the PHY? Can read out register 17h for these settings.

    - Are the networking settings compatible between the board and switch/PC (IP address, subnet, no firewall, ...)?

    I think this suggests an issue between the MDI of the PHY, and the RJ-45.

    Do you agree?

    After confirming above settings, I agree that the root cause is more likely on MDI side.

    Feel free to share the schematic to me over email, I can do a quick spot-check on MDI connections.

    Thank you,

    Evan

  • Hi Evan,

    Thanks for the detailed response.

     

    Q2a)

    Regarding:

    “Analog loopback test does not require external RJ-45 loopback, as this is only verifying signal chain between MAC<->PHY.”

    I was mistaken about the type of loopback I want to use. I’m looking for a way to loop-back in the Ethernet cable by connecting (full-duplex) RX+ RX- to TX+ TX-, without relying on a link partner (with second PHY) on the other side of the cable. In the diagram you posted this is labeled External Loopback, but it is not clear from the diagram the hardware required (to connect to the RJ-45) for the test.

    Is it true that External Loopback definitely needs a link partner (external PHY)?

    Q2b)

    My PCB has multiple DP83826s. Presumably, if an external PHY is required I can do External Loopback between DP83826s.

    Is this a possibility?

    Q3a)

    Regarding:

    “What is the MAC interface being used (MII/RMII)?”

    I am using the RMII2 of AM263Px.

    Q3b)

    Regarding:

    “If in RMII mode, is master/slave mode being used,”

    I intend to use RMII slave. This was recommended by TI.

    Q3c)

    Regarding:

    “what is the input clock on XI to the PHY?”

    Here is the CLK measured in two places on the PCB. If is routed to PHY1, and PHY2, and the trace is not short. Note the amplitude. This looks like a potential issue to me.

     Do you agree the XI Oscillator Input may be outside Recommended Operating Conditions?

    Q3d)

    I also do not see any oscillation on CLKOUT (DP83826 Pin 31).

    If DP83826.XI were good, I think I should see a CLK on CLKOUT.

    Do you agree?

     

    Q3e)

    Regarding:

    “Can read out register 17h for these settings.”

     

     

    The PHY is also configured to be in Enhanced Mode by DP83826.ModeSelect (pulled-up).

    Note: I am working on a prototype where the Bootstrap resistors are all manually soldered. There is potential for a mistake.

    The discussion in Q1) above is related to the PHY configuration. I was hoping, through analyzing the registers read by MDIO, that we could eliminate a configuration issue.

    I think that RCSR.5 is wrong. I think I need to set this bit in the driver. However, I do not think the wrong value would cause the auto-negotiation/link failure.

    Do you agree?

     

    Q3f)

    Is RMII Slave, or Enhanced Mode a concern?

     

    Q3g)

    Regarding:

    “Are the networking settings compatible between the board and switch/PC (IP address, subnet, no firewall, ...)?”

    I have been successfully testing LwIP with AM323x Control Card with the same test setup. I test with either a direct connection to PC on the same subnet, or through the switch shared in the prior post.

     

    Regards,

    Tollman

  • Hi Tollman,

    2a) External loopback does not require a link partner to the PHY, as the MDI data is looped back on the connector itself before transmitting to the link partner.

    Just a MAC<->PHY setup is enough for this test. Reverse loopback requires another PHY however.

    2b) If you have an RJ-45 interface between the DP83826's, reverse loopback is a possibility here.

    3ab) Thanks for confirming this setting.

    3cdef) For RMII slave mode, 50M clock input is required on XI. The PHY will not link unless the correct clock is supplied relative to master/slave mode. Switching to master mode (XI=25M) should resolve MDI side link, but may affect MAC-side communication.

    3g) Thanks for confirming.

    The cause for link failure is clear now, please let me know what options are available for either supplying 50M to XI, or reconfiguring the setup for the PHY in RMII master mode.

    Thank you,

    Evan

  • Hi Even,

     

    3cdef) 

    To avoid hardware rework and schematic change, I'd rather:

    •   operate the PHY in RMII slave mode
    •   reconfigure the AM263Px.CLKOUT0 frequency

    ... if possible.

    However, I do not see an easy way to accomplish this through SysConfig, driver API, …

    Is there a way to manage the clock on the AM263Px side?

    Caveat: Perhaps RMII Master is preferable anyway with the possible signal integrity issue with AM263Px.CLKOUT0 seen in the scope captures.

    Is this a valid concern?

    Q5)

    I do not see any advantage of operating the PHY in RMII Slave mode (other than not having to solder right now).

    I am simply connecting each AM263PX MAC to a PHY, and that PHY is connected (with magnetics, surge suppression…) to a RJ-45.

    Is there a scenario, with the configuration, where PHY in RMII Slave mode is preferable?

    Regards,

    Tollman

  • Hi Tollman,

    RMII master mode is the preference if there is larger distance between the MAC and PHY that can cause distortion / signal loss for the clock routing.

    RMII slave mode is preferable to reduce BOM cost and board size if the MAC is capable of supplying a valid clock to the PHY, rather than an additional crystal.

    I'm not familiar with AM263x API - to investigate possibility of reconfiguring CLKOUT frequency, please open a new thread for AM263.

    Thank you,

    Evan

  • I am exploring the DP83826 as RMII Master. Since I have three (DP83826) PHYs, it seems possible to:

    • Connect 25MHz crystal on XI and XO of PHY3.
    • Enable CLKOUT on PHY3, and route to PHY2, and PHY3. Note Datasheet, Section 9.1  "CLKOUT pin can be used to clock other modules on the system".
    • Bootstrap PHY3 Strap6 to Mode0 (CLKOUT 25 MHz on Pin 31)
    • Bootstrap all PHYs to RMII Master
    • Configure PHY3 in ENHANCED MODE to allow CLKOUT.

    Datasheet Figure 9-6 (below) shows a 50 MHz Reference Clock from PHY to MAC. 

    The following question assumes the three AM26Px MACs are each connected to the three PHYs as configured above.

    Question1a:

    Is the 50 MHz Reference Clock connected in this configuration, and if so, how is it connected?

    Question1b:

    Is the  AM263Px.CLKOUT0 connected in this configuration, and if so, how is it connected?

     

    Datasheet Excerpt 1:

    Datasheet Excerpt 2:

    Datasheet Excerpt 3:

    Regards,

    Tollman

  • Hi Tollman,

    1a) If the PHY is in RMII master mode, then the 50M clock output should be connected to the MAC's 50M RMII clock input.

    1b) Given that all PHYs in RMII master mode have suitable 25M clocks on their XI pins, the MAC's CLKOUT is not required to the PHY.

    Enable CLKOUT on PHY3, and route to PHY2, and PHY3

    One concern I have is the clock routing between PHYs here. Assuming PHY3's CLKOUT is shared between PHY2/PHY1, can you share details about the intended layout for this? What would the trace length be, and how would the clock split? Typically crystal input is placed close to the PHY XI pin to prevent distortion, so an extended and split CLKOUT could violate XI timing / integrity requirements.

    Thank you,

    Evan

  • Hi Tollman,

    Did you get a chance to get your schematics reviewed? Can you please share any update on this issue or if you need some support.

    Regards,
    Shaunak