• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 32 subscribers
  • Views 187 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DP83822IF: Receive Error Latch in Fiber mode.

Jon Mezo
Prodigy 10 points
Part Number: DP83822IF
Other Parts Discussed in Thread: AM5718,

Tool/software:

We are experiencing issues with the DP83822IF PHY in fiber mode. We are using an AFBR-59E5APZ transceiver. On the other end, there is a fiber-to-copper switch. We conducted a ping test from our device (in-house developed board with AM5718) to a PC, and everything works correctly. We disconnect the fibers, reconnect them, and it still works fine. However, when we reset the fiber switch (power off and on), communication does not return. The only way (so far) to make it work again is simply disconnecting and reconnecting the fibers.

The "trick" we're using to restore communication is periodically check register 0x0010, bit 13, which indicates a "Receive Error Latch". If at any moment we see it set to '1', we reset the PHY by writing 0x4000 to register 0x001f. This resolves the issue, but we'd like to understand what is happening, if anyone has experienced this before.

  • 0
    TI__Mastermind 25655 points

    Hi Mezo,

    When you are restarting the Fiber module, an software reset is required for DP83822IF.

    DP83822IF might still see the fiber module as link up if customer power cycle the fiber module. and software reset is required to restart the stage of DP83822 so that DP83822 is giving the link status of the PHY.

    --

    Regards,

    Hillman lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Hi Hillman lin,

    Thank you for your answer.

    When restarting the fiber switch, the DP83822 sees the link go down and then back up. The problem is that after the link-up, there is no communication. For the Linux driver we are using, everything seems fine. We haven't found any Linux driver for the DP83822 that does anything special in this case. How can it be determined that resetting the DP83822 is necessary? Is it correct to do it by reading register 0x0010, or is there a better way to do it? We cannot know when the switch is reset; it is an external device to ours.It can be shut down at any time without us knowing.

    At first, what we did was perform a reset every time we saw a link down. However, this didn't always work because if we used another switch that takes longer to start up, the solution wasn't valid. The PHY sees the link, but the fiber switch is still down.

    Regards,

    Jon.

  • 0 in reply to Jon Mezo
    TI__Mastermind 25655 points

    Hi Mezo,

    Sorry for the inconvenience. DP83822 required a software reset for the link indication to refresh on fiber application. Is it possible customer refer to the power down and power up the fiber module to inidcate DP83822 to perform a software restart?

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Hi Hillman Lin,

    We cannot know when the switch might turn off, and neither can the customer. It’s not something that will happen regularly, but it can occur (momentary power losses, maintenance...). If it does happen, we would lose communication.

    With our solution everything seems to be going well, but my question is: Are we ignoring something that could fail in the future?

    Best regards,

    Jon.

  • 0 in reply to Jon Mezo
    TI__Mastermind 25655 points

    Hi Mezo,

    Could you also refer Signal detect pin for software reset indication?

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Hello Hillman Lin,

    Yes, we do that, but it doesn't solve the problem. When the switch starts up, it seems that the fiber TXs are already powered on, and our AFBR-59E5APZ detects the signal (SD = '1'). Here, we reset the PHY, but it doesn't help because the switch hasn't finished booting yet, and we remain in an error state. To clear the error, we need to wait for the switch to fully boot before resetting. We have tested with different switch manufacturers and different SFPs, and it happens with all of them.

    The problem might be that the SD signal goes to '1' too quick, before the switch finishes booting. This causes the PHY to remain in a permanent error state.

    Best regards,

    Jon.

  • 0 in reply to Jon Mezo
    TI__Mastermind 25655 points

    Hi jon,

    Maybe setup a delay for software reset and see if that could help?

    --

    Regards,

    Hillman Loin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Hello Hillman Lin,

    Yes, we have already considered that as well. The problem is that different switches have different boot times. We've tested some that start up in 10 seconds, but there are others that can take up to 40 seconds. We can't risk setting a fixed delay and then having a new switch take even longer. These are critical systems that need to boot as quickly as possible. For instance, if we set a 1-minute delay to cover all possible switches on the market and the installed switch boots in 10 seconds, the system cannot be without communications for that long.

    Best regards,

    Jon.

  • 0 in reply to Jon Mezo
    TI__Mastermind 25655 points

    Hi Jon,

    Understood your concern. Software reset is required every time you change the stage of the SFP module. Unfortunately, DP83822 require an reset stage when there is a static change on the fiber module or link up. The only way we could do is resetting the PHY when system detect an error.

    --

    Regards,

    Hillman Lin