DP83867IR: Multiple PHYs on one MDIO Interface

Part Number: DP83867IR
Other Parts Discussed in Thread: AM62L

Hello everyone.

Currently I have a system which uses the AM62L and has only one MDIO interface.
We have one Ethernet PHY on the SOM and another one on the CB (carrierboard). 

Now I see an issue, that when the CB PHY is connected, the CB PHY refuses to answer.

Here is the scenario where only PHY0 is attached

phy0.png

Here is the scenario where only PHY1 is attached

phy1.png

In about 1 of 100 cases both work fine, but overall it behaves as above where only one is seen.

I also tried to set the SOM PHY to address 2, but it behaves exactly the same.

Do you have an idea what could be wrong here? Or what I can test?

Cheers

  • Hello,

    For clarity, in the above examples both PHYs are physically attached to the MDIO bus correct? Yet only one appears to respond at a time. I want to make sure there isn't only one PHY attached in each waveform.

    Is the responding PHY switching between PHY0 and PHY1 consistently, or does one PHY respond more often than the other when both are attached?

    Are there any components on the MDIO lines aside from the controller, the PHY, and one pullup resistor? (level shifter, multiple pullups,...)

    Are both PHYs able to link up and transmit data ok? 

    Best,

    Shane

  • Sorry. My bad. In the second one both are connected.


    During the bootloader all 32 addresses are polled. If only the SOM PHY is present, it will always respond correctly, same goes for the PHY on the CB when it is attached, but then the PHY on the SOM does not.

    The MDIO line has a PU to the same 1.8V that supplies the IO domain of the PHY on the SOM. It was 2.2k but I tried a 10k with no change.

    I didn't connect the MDI signals to the CB, as the module is soldered, so I did the MDIO connection with some flywires. But I do see a link if I connect a cable to the CB PHY.

    Currently I focused on the MDIO interface, as we use it in the EOL test. And I think this should work regardless of an MDI connection.

  • You're correct MDIO should work regardless of an MDI connection. Testing if the PHY is functional outside of the MDIO helps to know that the PHY itself is alive and ok.

    2.2k is good for the value of the MDIO pullup. Can you double check that the PHY's MDIO interface is not accessed within the first 200ms after powerup? This is T1 in the power up timings table/diagram:

    Does resetting either PHY have any effect on the issue?

    Does the MDC run constantly, or does it idle between operations? I notice in the plots MDC is constantly running so would like to check.

    Best,

    Shane

  • This is the the time between the reset pin and the MDIO. As the timebase is pretty big, the MDIO is only seen by the "noise". And the signal should be named MDIO not MDC, this is a typo from me.

    And here is the time between reset and MDC. Same issue here. Timebase is to big and causes the "voltage" drop of the signal

    Resetting the PHY does not help

    The MDC runs constantly while beeing in the U-Boot, as for whatever reason, the SoC tries to poll all available PHYs.

    I also tried to figure out if the error is pinned to the specific adress. But switching the SOM PHY to 2 and the CB to 0, doesn't change the behaviour. As even then only the CB PHY is seen.

  • Issue was a second edge, which caused the PHY to send data to early.

    This have not been an issue with the first revisions of the AM62L because if it driver bug, where everything was set to slow by default. With this fixed, this needed to implement in order to stabilise this behaviour.

    There is still a step, but this because of the testfixture.