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.

DP83869HM: DP83869HM Fiber mode demo configuration code, LINK issue

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869,

Hi Team,

Can you help check below the possible reason for below DP83869 LINK issue in Fiber mode?

Customer need MII to 100Base-FX mode, didn't use hardware strap, and they configure register as MII to 100Base-TX guidance in https://www.ti.com/lit/an/snla318/snla318.pdf.

However, when customer plug in fiber cable again after pull out fiber cable, DP83869HM cannot recognize it as Link up.  Moreover, if the customer adds judgment logic in the software to waits for the PHY link up before sending data from the MAC to the PHY, this problem will be reduced. This seems like DP83869 Fiber link judgement will be affected by MAC--MII data transmission. 

Below is their configuration code.

1. Can you pls help check if there is any issue in their configuration or provide a DEMO code for DP83869HM fiber configuration? MII--100Base-FX mode.

2. Can you pls help clarify the link status judgement logic in DP83869 fiber mode? Is this issue caused by the affection of MAC--MII data transmission?

Thank you!

Yunjing

  • Hello Yunjing,

    In the app note you mentioned, I see that following steps have been mentioned (1.11.1) :

    Required register configuration when switching to RGMII-to-100Base-FX mode using software:

    • Write 0x0042 to register 0x01DF

    •Write 0x2100 to register 0x0C00

    • And in the end write 0x4000 to register 0x001F

    Is your code executing these?

    --

    Regards,

    Vikram

  • Hi Vikram,

    This is RGMII to 100Base-Tx, full duplex mode configuration. Customer need MII to 100Base-Tx, half duplex mode.

    So their code execute as below. 

    • Write 0x0062 to register 0x01DF

    •Write 0x2080 to register 0x0C00

    They didn't  write 0x4000 to register 0x001F to restart the PHY circuit, but this restart is used for 1.11.1(special use case: need switch between copper and fiber).  It shouldn't necessary for normal Fiber use case(no Media switch), right? 

     

    If above code is right for MII-100Base-Tx, half duplex mode, it seems that the link status judgement logic in fiber mode is affected by MAC to PHY data transition. Can you pls help clarify the link status judgement logic in DP83869 fiber mode? Is this issue caused by the affection of MAC--MII data transmission?

    Thanks & Best regards

    Yunjing

  • Hi Yunjing,

    Sorry I am a little confused. Does customer wants 100BTx or 100BFx? 

    If we are switching modes (from default strap mode) we recommend writting register<0x001F>=x4000.

    Link-status on fiber should not get impacted by what is happening on MAC side.

    --

    Regards,

    Vikram

  • Hi Vikram,

    Sorry for the typo. They wants MII to 100BFx, fiber mode, not switching modes.

    They configure the registers as below, and they add a link status judgement logic before MAC to PHY data transition, this issue resolved.

    • Write 0x0062 to register 0x01DF

    •Write 0x2080 to register 0x0C00

    •Link status judgement before MAC to PHY data transition

    That is, after add the link status judgement, when customer plug in fiber cable again after pull out fiber cable, DP83869HM will finally recognize it as Link up.

    My question is, according to this issue and above solution,is there any special requirements for DP83869 Link detection? Such as detail delay time requirement before query Link status.

    Thank you

    Yunjing

  • Hello Yunjing,

    If there are no straps used with the 869, it will by default boot-up in Rgmii to Copper mode. So in the present use-case, after power up in Rgmii to copper mode customer is switching to MII to 100BFx (fiber) mode using register writes. Hence we recommend adding register<0x001F> = 0x4000.

    But I am not sure if that is the root cause of the issue. Can you confirm that my understanding of issue is correct by answering the following questions:

    1. After writting above registers, does it take long time to link or link never happens?

    2. After writting above registers, if customer removes the cable and plug it back link always happen. Correct?

    3. What is customer doing in "link status judgement" logic? 

    4. Is there a resistor connected on "tx_disable" pin of SFP to ground? What is the value of that?

    --

    Regards,

    Vikram

  • Hi Vikam,

    Sorry for late reply cause National holiday. Pls check my feedback below. 

    1. After writting above registers, does it take long time to link or link never happens?

    After writting register<0x001F> = 0x4000, DP83869 sometimes can Link with SFP, but still cannot link at some time.

    2. After writting above registers, if customer removes the cable and plug it back link always happen. Correct?

    No, only if they add the ''link status judgement logic'', link happens.

    3. What is customer doing in "link status judgement" logic? 

    As I wrote in the 1st post of this thread,''' the link status judgment logic '' is to waits for the DP83869 register read as PHY and SFP link up, then send data from the MAC to the PHY. In this way, this SFP link issue will be reduced.

    4. Is there a resistor connected on "tx_disable" pin of SFP to ground? What is the value of that?

    Below is the SFP connection(J3-A), but customer didn't connect the 'SFP_disable' to GND resistor R160. Can you pls. help clarify what issue would cause by this resistor?


    Seems adding <0x001F> = 0x4000 cannot shot the root reason, do you think their software configuration code and hardware schematic will helps find the root reason? If so, I can share those with you by email.

    Thank you & Best regards

    Yunjing

  • Hello Yunjing,

    Thanks for the answers. This is what I derived from your explainaiton :

    "DP83869 after programming to Rgmii - 100BFx mode sometimes does not link-up or links up late with SFP. Customer is reading the link status register to ensure that link is up and then sends the data from MAC to SFP." 

    I my above understanding is correct then I can confirm that yes link between phy and SFP has to be up before the data transfer can be successful.

    Further suggestions :

    1. Kindly share the SFP module model number and I will check if we already have any data for this SFP?
    2. Who is the link-partner on other side of the fiber cable? Has customer checked that there is no problem with the link-partner that is causing delayed link?
    3. For some SFPs we have seen that link-up is more robust if we have around 600 ohms of pull down on tx_disable pin of SFP. Can we try this?

    --

    Regards,

    Vikram

  • Hi Vikram,

    Thanks for support.

    After the test with another SFP module, it turns out the issue is caused by customer's SFP module. 

    Can you pls. help list some SFP module and Fiber-to-Copper SFP modules that we have tested and verified in your side for customer's reference?

    Many thanks!

    Yunjing

  • You may refer to above e2e thread. We listed down a few 100B-FX and 1000B-FX SFPs that we have seen being used in field with 869 and customers may test their system with same.

    --

    Regards,

    Vikram

  • Hi Vikram

    Got and thank you!

    Best regards

    Yunjing