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.

DP83848-EP: PHY Component Intermittently Powering up in Bad SSD Mode

Part Number: DP83848-EP

Hello,

We have been using the DP83848-EP in our Ethernet system for some time now but what we are seeing that we are unable to establish link approximately 50% of the time. The only way to establish link is to power cycle the board until it works or manually pull the RESET line low. What we found is that when we power up in a faulted state the component is indicating that it is in a Bad SSD state. This can be proven by measuring the RX_ER and the RXD[3:0]=1110. When connecting the RX_ER line up to a o-scope what we see is that this line will be HIGH and "pulse" LOW every ~16uSec for ~100nSec. Another key point about our set up is that we are not sending any commands/messages to he PHY chip during this time, we only have it connected to a laptop running wireshark. Also what we have found is that we only see this off nominal condition with certain code loads on our FPGA, there is no issue with some code loads. We have looked at the power up plots (X1 CLK, Reset, 3.3V, etc.) and everything looks nominal.

What it looks like to me is that the PHY chip is thinking that it is receiving a message and expecting the /J/K/ pattern and not receiving it. Then getting stuck in some kind of loop until we reset or power cycle

Have you seen anything like this before? Is there something about how we initialize the PHY chip with the FPGA that could cause this condition?

Thank you,

Andrew Wiley

  • Hi Andrew, 

    Can you clarify if the link is established in the faulty state you've described? Without a link established on the MDI, the PHY will not be able to process data over the MAC interface. 

    Can you also describe the differences between the FPGA code that causes the faulty state from that of a good setup? Does the FPGA control pins connected to the PHY that could be affecting the bootstrap settings of the DP83848? For instance, configuring an FPGA pin with a pull-up resistor that could over-power the internal pull-down resistor of the PHY during power-on or reset?

    Regards,
    Justin

  • Justin,

    No we cannot establish link while in the faulted state. At this point in our testing we were not sending any commands or messages. Just powering up and checking link. This is the part that is confusing me, from my understanding to get in this Bad SSD mode there needs to be a message/command on the input lines.

    As for the difference between the FPGA code loads, there is no difference in functionality of the I/O pins between the FPGA and the PHY. The only differences are between the FPGA and the down stream components.

    Thank you,

    Andrew Wiley

  • Hi Andrew,

    Does issuing the following resets to the device resolve the issue, in all cases:

    1. Hardware reset - de-asserting RESET_N low and releasing?
    2. Software reset - writing 0x8000 to register BMCR (0x0000)?

    The first debugging step, I would investigate, is how to bring up the link consistently. Then I would evaluate the MAC interface, since the PHY will not process this data without a link. 

    You mention that power cycling the boards may results in repeated bad states without link and then a successful link with no issues. Is this correct? This points to a power-up timing marginality or strap threshold marginality that may be latching in a different value on some power cycles. 

    Are there code loads that are shown to cause the issue and different code loads that never see any issue? Or is the issue present on some percentage of loads, regardless of the code executed?

    Regards,
    Justin 

  • Justin,

    Yes a hardware reset will resolve our issue. We have not tried a software reset.

    We are looking into the power up scope plots and have not found any issues. To touch on your final question yes there are some code loads that does not have this issue. In my mind if there truly was a power up issue then it would be there for any code load (i could obviously be incorrect about this).

    Other issue that we could potentially be seeing is "far end fault detection". There is not much about what causes this condition in the data sheet but a quick online search tells me that when we are in this state we lose link and the only way to clear this bit is to reset the PHY or read the bit. What exactly causes this condition? Does TI have more documentation on this issue?

    Thank you,

    Andrew Wiley

  • Hi Andrew,

    The far end fault detection is a feature that will notify the PHY through the auto-negotiation FLPs that its link partner has experienced a fault causing the link to drop. Reading this register (0x0001) will clear the fault and the PHY can re-establish link if the fault at the link partner has been resolved. Please let me know if reading this register resolves the issue as well as the result of the software reset. Can you also provide information about the link partner you are using? 

    Can you please share the register information of the DP83848 during a faulty setup and then the register info after a hardware reset? Please also share the schematic. 

    Can you also describe what the differences are between FPGA code that does not result in faulty setups and FPGA code that does? I'd like to confirm that the PHY LED, RX data pins, and XI are not being affected by the FPGA. 

    Regards,
    Justin 

  • Justin,

    It does not look like we have the far end fault detection bit set. Dose the PHY put 1110 on the RX_D lines and assert the RX_ER line HIGH when we are in this faulted state? I would have to verify that I can share the schematics (ULA PI).

    To answer your other question, there is no difference between the FPGA code loads associated with the PHY. Another note is that we configure the PHY purely by external PU/PD as recommended in the datasheet. We do not initialize the PHY using the FPGA (MDC/MDIO).

    I would like to circle back on the Bad SSD that i am seeing when we are in the bad state (This is the only physical evidence it have about what state the PHY is in). It looks to my that the PHY is getting into an infinite loop thinking there is a command coming in and not receiving the /J/K/ pattern. Is this a common fault mode of the PHY? 

    Thank you,

  • Hi Andrew,

    The state of the RX data pins does not affect the establishment of link on the MDI of the the PHY, that is why I am focused on the bootstraps, registers and power-up settings of the PHY. 

    Please provide register settings for 0x0000-0x001F in both the faulty state and good state as well as the schematic. 

    I understand that there is no difference between to the PHY between a "good" FPGA code and a "faulty" FPGA code, but can you help me understand why some code loads are consistently able to establish link and some are not? This would appear to me to be an important data point in determining a root cause, is there something that I am missing by disregarding this? Is there a difference in the execution of the code that could affect the timing when pins are initialized?

    Regards,
    Justin