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.

DP83867IS: Continuous Operation Test Anomalies

Part Number: DP83867IS

Dear Texas Instruments Support Team,

We need help with an issue related to the DP83867ISRGZ Ethernet PHY. The problem and information we require are outlined below:

Issue Description:
Our board, which employs this component, is currently undergoing continuous operation tests. After running the tests for several tens of hours, there were a few times the PHY starts to consistently return only 0xffff when the MDIO interface is used to read status registers.

Board Configuration:
The CPU is an NXP T1024 connected to the PHY. There are four PHYs connected, two through SGMII and two through RGMII. The MDIO lines are connected in two separate systems, pairing one SGMII PHY with one RGMII PHY.

Observation on MDIO Lines:
When monitoring the MDIO lines with an oscilloscope, it is observed that the waveform from the CPU to the PHY appears normal, but the waveform from the PHY to the CPU is consistently high. Interestingly, this problem does not happen with the other PHY on the same MDIO line.

Reset Attempts:
After this problem occurs, normal operation does not resume. Asserting a reset in the Basic Mode Control Register (address 0x0000) does not fix it. The normal operation can be restored either by power cycling or by asserting the RESET_N on the PHY's external pin 43.

Data Exchange Post-Issue:
After the issue persists and the consistent readout becomes 0xffff, the data exchange between the CPU and PHY through SGMII/RGMII remains normal.

MDIO Line Configuration:
Two PHY devices are connected to a single MDIO line. The CPU controls MDIO line access exclusively using software, and there are no issues with its operation.

We would appreciate any information you have regarding potential errata related to this behavior:

* Have there been any similar instances in the past, and if so, what solutions were implemented?

* Additionally, apart from external factors like electrical noise, are there other possible causes for this issue?

Your assistance in resolving this matter would be greatly appreciated. matter and look forward to your expert advice.

Best regards,

  • Hi Hiroshi-san,

    Thank you for sharing your observation. We would like to ask couple questions to confirm on the setup

    Please correct me if my understanding is wrong.

    • There are few DP83867PHY is reading FFFF when after ten hours.
    • Only hardware reset or power cycle could fix the MDIO reading issue
    • What temperature are you operating the system?

    If possible, may I see a screenshot of the waveform of MDIO/MDC lines?

    If possible, could you also provide an schematic around MDIO/MDC lines?

    • We want to double check if there is an external pull up resistor on MDIO lines but not on the MDC lines
    • Make sure no external signal near the MDC lines.

    ---

    Thank you,

    Hillman Lin

  • Dear Hillman Lin,

    Thank you for your follow-up questions. I am providing clarifications and additional information as requested:

    Confirmation of Observations:

    • Yes, your understanding is correct that some DP83867PHYs start reading FFFF after about ten hours of operation.
    • Yes, only a hardware reset or power cycle can resolve the MDIO read problem.
    • The system operates at room temperature.

    Waveform of the MDIO/MDC Lines:
    Unfortunately, we do not have a saved waveform of the MDIO/MDC lines from when the problem occurred. However, we will make sure to capture this data if the problem reoccurs and will share it with you.

    Schematic of MDIO/MDC Lines:
    Sharing the complete schematic is not feasible, but we can provide a partial schematic that specifically includes the CPU and PHY MDIO lines. Would this be sufficient for your analysis?

    Pull-Up Resistors on MDIO Lines:
    After checking, both MDIO and MDC lines are equipped with pull-up resistors.

    Proximity of Other Signals to MDC Lines:

    • We have maintained a minimum distance of at least three times the width of the line between the MDC lines and other lines or ground.
    • Where other lines are close, they mostly carry signals with minimal level changes (e.g., signals from DIP-SW).
    • However, there is one section where the RGMII TX_EN signal runs parallel to the MDC line for about 45mm.

    I hope this information helps you with your analysis. I look forward to any further guidance or suggestions you may have.

    Best regards,

  • Hi Hiroshi-san,

    Thank you for sharing the information. Because the MDC lines is internally Pull down for DP83867PHY. We don't recommend MDC to have a pull up resistor.

    Could you check if removing the pull up resistor on MDC lines help with your current issue.

    Meanwhile, I will wait for your waveform.

    --

    Regards,

    Hillman Lin

  • Dear Hillman Lin,

    Thank you for your advice regarding the pull-up resistor on the MDC lines. Here's an update and our plan for moving forward:

    Removing Pull-Up Resistor on MDC Lines:
    Once our current verification processes are complete, we plan to test the system by removing the pull-up resistor on the MDC lines, as you suggested.

    Additional Findings Under Review:
    We've come across a potentially relevant issue that is currently under investigation. Initially, as discussed in this TI E2E forum thread (*1), the PHY's CLK_OUT was connected to the CPU's 125MHz clock input. However, we found that this clock did not provide a stable 125MHz output immediately after startup. Therefore, we now use a signal from an OSC for the CPU's clock input. Despite this change, the PHY still extends about 60mm from CLK_OUT, and we had not disabled the CLK_OUT output. After disabling the CLK_OUT output in the PHY’s register settings, we observed that the problem of reading data as 0xffff did not occur on two boards running continuously for a week.

    Waveform Data:
    Due to the positive results of the above adjustments, we have not yet been able to capture the waveform data during the problem. We will continue to monitor the situation and will share the waveform if the problem reoccurs.

    We appreciate your continued support and will keep you informed of any further developments.

    Best regards,

    (*1) DP83867IS: Register setting for 125MHz output to CLK_OUT
    e2e.ti.com/.../dp83867is-register-setting-for-125mhz-output-to-clk_out

  • Hi Hiroshi-san,

    Thank you for your detail update. Glad that you are able to see positive result. Please let us know if you have further questions.

    --

    Regards,

    Hillman Lin