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: Startup Failure

Part Number: DP83825I
Other Parts Discussed in Thread: DP83826E

Tool/software:

Hi,

I have a circuit with two ETH interfaces. The main processor is a imx6ULL. I use two dp83825I.

I attached pictures of the schematic where those components are involved. The software is made by the customer. 

Just for your information, they already made working systems with the same processor, but with the DP83826E.

Yes, the power supplies start up together and the linux system brings the clock over the ENETx_TX_CLK. Both is not optimal and has to be improved in a redesign. 

But I am facing the following problem: 

After the linux is running I have a functional connection to ETH1 but ETH0 is just sometimes working correctly. After a linux reboot, ETH0 is also working. 

I can not explain what happens to eth0 during the reboot. 

Might it be something with the strap pins? 

Any help is appreciated.

Kind regards

Cédric

DP83825i-Schematic.pdf

  • Hi Cedric, 
    Can you verify that the clock is available at the power ramp of both PHYs? If not, the PHY can go into the bad state and not respond. Assuming the linux reboot doesn't power off the PHY, it may be that the PHY is resetted into a good state. 
    In addition, is it possible to send MDC/MDIO reads to see if ETH0 responds to other PHY addresses? If the strapping is not soldered correctly, wrong PHY address could have been strapped and is not responding to the Linux's commands. 
    How often does this issue happen for ETH0 and how many devices have run into this issue?

    Best,
    J

  • Hi J

    No the clock is not available at power ramp. The power supply is direct after start up here. The imx6ULL starts the clock just after power up. 

    Assuming the linux reboot doesn't power off the PHY, it may be that the PHY is resetted into a good state. 

    How can the phy get into good state. I also thought about this. 

    I have to check with the software team if I can get the MDC/MDIO reads. Or do you mean with the Oszilloscope? 

    Might the LED0 PIN be a problem? that i made a mistake with strapping this pin correctly?

  • It does seem that the led0 pin is strapped to disable autonegotiation but linux should not have an issue detecting the PHY. Could the customer try doing a second reset after the first reset and see if that fixes the issue?

    Best,

    J

  • Sorry for my late response.

    We just ordererd some new PCB with defined startup and external quarz as well two independet reset lines. 

    Because one PHY always worked I think that the nxp might made the problems inside the kernel /bootloader. 

    So we can close this thread and if I have further questions with the new board i will open a new one. 

    Thanks!

  • Hi, 

    The thread will automatically lock after 30 days so feel free to continue on this thread if this thread doesnt lock, or open a new one. Please let me know!

    Best,
    J