• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 32 subscribers
  • Views 464 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.

DP83822I: Missing link after switching from auto-negotiation to forced mode

Stefan Pape
Intellectual 820 points
Part Number: DP83822I
Other Parts Discussed in Thread: AM4376

Hello experts,

on our hardware platform we are using two Ethernet PHY tranceivers of type TI DP83822I. Both PHYs are connected via MII interface to an AM4376 CPU and are used with the ICSS_EMAC (EtherNet/IP adapter with DLR support).

When the PHYs come out of reset (RESET_N = high), they are configured the first time using MDIO interface (CSL_MDIO_phyRegRead/Write):

  1. Disable IEEE power-down-mode (BMCR bit 11 = 0)
  2. Disable RGMII and RMII mode and switch to MII mode (RCSR bit 9,5,7 = 0)
  3. Set low polarity for LED 0 (LEDCR bit 7 = 0; PHYCR bit 5 = 0)
  4. Enable interrupts ...
  5. Enable Auto-MDIX (PHYCR bit 15 = 1)
  6. Set auto-negotiation capabilities (ANAR bit 8-5 = 1)
  7. Enable and restart auto-negotiation (BMCR bit  12,9 = 1)

In this configuration, link is established successfully and everything is working fine. The setup sequence above is executed on driver layer and is used to set the Ethernet interface to a default operational state.

When changing the speed and uplex configuration to forced mode, e.g. 100 MBit/half-duplex with auto-negotiation disabled, no link is being established. This error occurs when the following configuration sequence is executed very soon after step 7 (above):

8. Disable auto-negotiation (BMCR bit 12 = 0)

9. Set speed and duplex mode to 100 Mbit/HD (BMCR bit 13 = 1, bit 8 = 0)

This re-configuration is done by the application applying the user configuration for both Ethernet ports. Step 8 seems to be the problematic part:

  • When waiting for a stable link signal after step 7 and then execute step 8, a link will be established at 100 MBit, HD.
  • When not waiting for a stable link (or an unknown timeout without an Ethernet cable), the link will not be established. Unplugging and re-plugging the Ethernet-cable does not fix the problem.
  • Skipping steps 5-7 does not fix the problem, either. I did not expect this, because steps 5-7 do not change the default configuration of the PHY.

What has to be done to re-configure the PHY from auto-negotiation to forced mode in order to get a stable link signal (parallel detection)?

Thank you in advance.

Best regards

Stefan Pape

  • 0
    TI__Genius 9920 points

    Hi Stefan,

    When you make these changes, is your link partner still in auto-negotiation and auto-MDIX or have you also changed them to be in forced mode?

    Could you try enabling robust-mdix and see if that creates a link?

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Intellectual 820 points

    Hello Cecilia,

    thank your for your quick reply to my request.

    Yes, in error case the link partner is in auto-negotiation mode with enabled auto-MDIX. This is one of our test szenarios in which the user may have forgotten to change the intreface configuration of the link partner.

    Enabling the robust-mdix function solves this issue but it seems to make the link establishement much slower, even with auto-negotiation enabled on both link-partners.

    Best regards

    Stefan

  • 0 in reply to Stefan Pape
    TI__Genius 9920 points

    Hi Stefan,

    How much slower is the link establishment using robust-mdix?

    And I know above you mentioned that removing the cable and plugging back in did not solve the issue but have you tried doing a soft reset? This is done by writing 4000 into register 0x1f 

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Intellectual 820 points

    Hello Cecilia,

    I did no explicit measurement for the link establishement time. I watched the LED0 after the restart of our device and observed that LED0 sometimes remains off for up to 4 s before it goes on. Without enabling robust-mdix, LED0 switched to on state within 1-2 s.

    Writing a 0x4000 to register 0x1F issues a "Digital Reset" and does not interrupt the deadlock condition. I already tried to do that.

    Writing a 0x8000 to register 0x1F issues a "Software Reset" and interrupts the deadlock condition. But it also resets the configuration to default value including autonegotiation enabled. So I would be in the same situation as before.

    Best regards

    Stefan

  • 0 in reply to Stefan Pape
    TI__Genius 9920 points

    Hi Stefan,

    Thanks for letting me know that you have tried the resets as well. 

    I will need more time to investigate this further. 

    With your scenario in which your link partner is set to auto-negotiation is it only advertising certain speeds and just half duplex? 

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    TI__Genius 9920 points

    Hi Stefan,

    I spoke to my team about this test scenario. It looks like what you had shared on your e2e question is an expected behavior. For the DP83822, you will lose link if you have enabled auto-neg + forced mdi/mdix OR forced speed + auto-mdix you will either have to have both forced modes or both auto enabled.

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Intellectual 820 points

    Hello Cecilia,

    to your reply from April, 23th:

    No, in test case, the link partner was a general fast and gigabit desktop switch offering default speed and duplex abilities.

    to your reply from April, 24th:

    If I understad you right, the DP83822 is not able to do auto-neg without auto-mdix enabled and vice versa. Is this correct?

    I did not find a hint about such a dependency in the documentation (data sheet/manual/errata). We are using the PHY with your PRU EtherNet/IP adapter with DLR support. If the DP83822 is not able to operate in forced speed/duplex with auto-mdix enabled, it will not pass the current EtherNet/IP conformance test. During the test, speed and duplex will be forced while auto-mdix is enabled. When the test switches from auto-neg to forced speed it fails due to link loss. 

    In your EtherNet/IP adapter v1.0.3.4 example code, the DP83822 was referenced (see board_dp83822.c). Within the implementation I did not find any workaround for the auto-neg/mdix issue (e.g. enabling robust mdi-x). But for the DP83867 there is a workaround, where auto-mdix is done by software, if the PHY is switched to forced speed (see board_tlkphy.c > Board_tlkMDIXTask).

    So I am a little confused about which solution/workaround shall be implemented:

    • Just enable robust auto-mdix? Seems to work but is quite slow.
    • Implement a software based Auto-MDIX function? I do not expect that it will be faster than robust auto-mdix.

    Is it possible to achive an EtherNet/IP Declaration of Conformity when using the DP83822?

    If yes, what kind of workaround shall be used/preferred?

  • 0 in reply to Stefan Pape
    TI__Genius 9920 points

    Hi Stefan,

    The solution for this would be to use Robust-MDIX. We have made it a point to make it more clear in our datasheet that this is the option to select when performing non-normal Auto-MDIX functions (Mentioned in table 24 of the register map 0x0009)

    Are there concerns for the slow performance on enabling robust auto-mdix? What are your spec requirements for this?

    Thanks,

    Cecilia

  • 0 in reply to Cecilia Reyes
    Intellectual 820 points

    Hello Cecilia,

    we don't have any requirements for the link-up time. In most cases, the link-up time does not take into account, because it elapses while the device is performing the power-on reset. Only if an Ethernet cable is plugged during runtime, the user recognizes that the link-up takes much more time than it does on other devices (with the same network setup).

    So enabling Robust-MDIX will be the short-term solution to achive a stable link-up behavior.

    Thank you for the support.

    Best regards

    Stefan