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.

DP83867E: MDIO access issue for specific sample(1pcs/50pcs)

Part Number: DP83867E

Tool/software:

Hi team,

[Problem]

My customer is facing issue that MDIO can't be accessed sometimes for only single sample out of 50pcs. The issue happened 1~2 times out of 10 times power cycles for the unit.

There is no response to the MDIO access when the issue occurs, and the register value cannot be read. (It has been confirmed with a waveform that there is no response.)

Performing a hardware reset when the issue occurs allows MDIO access.

[Assumption]

He doesn't think the issue cause by PCB because it recovers by hardware reset. He doubts incorrect strap setting which leads to wrong PHY address setting when power-on.

[Question]

The datasheet states "The information is latched into the device at a device power up or hardware reset".

For now, the device starts up with RESET_N Low when power-on. Then, RESET_N is released after more than 500ms.

Is powering up with remaining RESET_N Low compliant to below condition for latching properly?

Best regards,

Shota Mago

  • Hi Mago-san,

    Could the customer send us the scope capture of power sequence?
    In addition, could they check what the voltage of RBIAS to see if the PHY is alive.
    If it is alive, could they try to read all of the PHY addresses to see if unintended address strapping happened. 

    If none of them work, since it is just one unit, could the customer try to put the good PHY on the suspected PCB and see if they can read the registers on that PHY? Also, could they send us the schematic so we can take a look at the strap configurations and MDIO/MDC lines?

    Please let me know.

    Best,

    J

  • Hi J,

    Attached is power sequence. VDDA1P8 pin is open because the customer uses the device with two supply configuration.

    It's difficult to check all PHY addresses because software is running.

    RBIAS voltage was 1V for both normal unit and defective unit.

    CH1:VDDA2P5

    CH2:VDD1P0

    CH3:VDDIO(1.8V)

    Best regards,

    Shota Mago

  • Hi Mago-san,

    And the reset pin is low throughout the power sequence? When does the reset pin go high?

    Best,

    J

  • Hi Mago-san, 

    After internal discussion, it would be great if the customer could run all the PHY addresses after the startup of the problematic PHY to see if the PHY is strapping to the wrong PHY address. Could you try to convince the customer to do this?

    The power sequence looks good. 

    Best,
    J

  • Hi J,

    Update will be May 8th due to national holidays in Japan.

    While, have you ever seen similar issue in the past at another customer?

    Best regards,

    Shota Mago

  • Hi Mago-san,

    No, we have not yet heard such case from our customers.

    Please let us know after the holuday.

    Best,

    J

  • Hi Mago-san, 

    I reviewed the waveform and I noticed that the RESET_N unintentionally goes up to 1Vish for a bit. Because Vih is 1.26V so the pulse shouldn't affect the RESET stage but it may due to the slow ramp up to 1V. I'd assume the customer uses the same logic device for all the boards with our sample. Has the customer noticed the same pulse on other boards with our sample?

    It would still be great if the customer can test with all PHY addresses to see if they can MDIO access with the problematic PHY. 

    I reviewed the schematic, and there is nothing notable either. Another thing I can think of is that the oscillator the customer uses is out of our recommended specification. Could you also check the oscillator specification with the customer?

    Please let me know. 

    Best,
    J

  • Hi J,

    The customer confirmed that the pulse on RESET_N occurred at correct samples as well. He fixed the pulse, but the MDIO issue still remains.

    I'm asking the customer about if they can check all PHY address again.

    Best regards,

    Shota Mago

  • Hi Mago-san, 

    Sounds good. Please keep me updated. If they cant read all the PHY addresses, it would be also great to see if they can take the problematic PHY to the working board and see if there are any MDIO problems, or have the working PHY put on the problematic board and see if the registers can be read on the PHY. 

    Best,
    J

  • Hi J,

    The customer confirmed that when the issue occurs, PHY address is returned as "0000".

    Meanwhile, when the device works properly, PHY address shows "1111" as expected following pin strap setting.

    Best regards,

    Shota Mago

  • Hi Mago-san,

    It looks like the PHY is taking the wrong strapping configuration at the startup. Could they do an ABA swap on both the board and the PHY?

    Best,

    J

  • Hi J,

    Sorry for late update.

    My customer said it's difficult to do an ABA swap because of VQFN package and so far he will not ask external service to rework.

    He also checked RX_D0/RX_D2 voltage, but both of them are normal.

    When does the PHY read strap setting? The datasheet states it latches hardware configuration pins at power-on or reset, but the customer would like to know more details like as follows.

    1. At what timing of the hard reset (falling edge or rising edge, and timing) 
    2. When does latch occur(How long ms after which power supply turned on)

  • Hi Mago-san, 

    I understand that ABA swap might be challenging. 
    Please refer to this chart for the timing of strapping:

    At what timing of the hard reset (falling edge or rising edge, and timing) 
    When does latch occur(How long ms after which power supply turned on)


    Given that XI is provided prior to power-up, strap latch in happens 200ms after the VDD and RESET_N going high.


    I discussed internally with the team and we believe that customer should be able to see any changes on RXD0 and RXD2 pins when the PHY properly straps and when the issue occurs. Could the customer take waveforms of RXD0 and RXD2 pins when the issue occurs and in the normal state to see what that change could be?

    Please let me know. 

    Best,
    J