DP83869HM: Different Behaviour Rev.1 and Rev.3

Hi Kaya,

I would like some clarification on your setup. Please correct me if I misunderstand your setup:

• 869 (Rev.1) < -- copper side --> 869(Rev.3).
• For Rev.1, when there is no FO cable on the Fiber side, the copper link drop
• For Rev.3, wen there is no FO cable on the Fiber side, the copper link does not drop

Did I understand your concern correctly? If so, could we check some register value to double check on your setup?

• Could you read 0x006E, 0x0001, 0x0018, 0x0005, 0x0037, and 0x01DF on both with FO cable and without FO cable.

--

Thank you,

Hillman Lin

Hi Kaya,

After I discuss with the team internally. The different between revision 1 and revision 3 for DP83869 is revision 1's 0x0001 register won't determine the Fiber link up fiber link up need to be detected on 0x0C01[2].

DP83869 revision 3 can determine both fiber and copper link drop through register 0x0001.

The following App note will have more detail:

https://www.ti.com/lit/an/snla305/snla305.pdf?ts=1694455927358&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83869HM

--

Regards,

Hillman Lin

Hi Hillman,

Thank you for your prompt reply.

For your first reply, please find my answers below:

• Internal PHY in Switch Engine (KSZ9897R, Microchip) <-> copper side (MDI) <-> DP83869HM(Rev.3) <-> fiber side <-> SFF Transceiver
• That is correct, in case of Rev.1 after initialization(power-on) after ca. 8-10 seconds, the link on copper side drops. If switch engine sends frames, No frames are sent to SFF transceiver, LNK Led for both copper&fiber side and ACT LED is OFF. 
• That is correct, in case of Rev.3 after initialization(power-on) without FO Cable, the link on the copper side never drops, both copper side PHY and DP83869HM shows no link. But strangely, when frame comes from switch engine to DP83869HM, the frames are sent to SFF Transceiver. LNK LED on copper side is ON, fiber side Link LED is OFF, ACT LED flashes. When a FO cable is plugged in and out, then everything goes normal as Rev.1. The same result also occurs by deactivating LLP.

The below register readings belong to Rev.3 without FO cable:

6Eh = 0x0a5c

1h = 0x7949

18h = 0x0150

5h = 0x0000

37h = 0x0000

1DFh = 0x0045

The below register readings belong to Rev.3 with FO cable:

6Eh = 0x0a5c

1h = 0x794d

18h = 0x0150

5h = 0x0000

37h = 0x0000

1DFh = 0x0045

The register readings for Rev.1 are same as Rev.3

For your second reply, please find my answers below:

The given application note belongs only to Gigabit Media Converter. Is this still applicable 100M Media Converter? We have never encountered with Link Issue. Therefore we have not used this AN for our application. After startup of the board(resp. the initialization) without any cable inserted, all related registers show Link Down as usual on both side but DP83869HM continues to behave as there is Link on the copper side and transmits the frame to the transceiver.

The same problem is also given in the below post, but the user reported, that this is related to some PHYs of specific LOT. Do you have any PHY belongs to the same LOT number? Unfortunately i do not know whether our PHYs belong to the same LOT or not. But On the chip itself the following markings are given (DP83869HM, TI, 31F, S161, G4). One of them should be LOT trace code but i do not know which one.

(+) DP83869HM: LED_0 is on at boot time. - Interface forum - Interface - TI E2E support forums

Hi Kaya,

Similar behavior is also observed 100baseTX to 100baseFX as well. 

The behavior you are seeing follows the expected trend between Revision 1 and Revision 3:

• In 869 revision 1, we are expecting 0x0001[2] link status update only on the copper side but not the fiber side. If fiber is disconnected on the fiber side and you are still seeing link up in copper side. Then register 0x0001 won't update. If you want to know when is the fiber drop or link down, you need to read 0x0C01[2] to see the link drop on fiber side.
• In 869 revision 3, we are expecting 0x0001[2] link status update when copper side link drop and/or fiber side link drop. Therefore, when you disconnect the fiber side, 0x0001[2] link status will display as link drop as well. This is what customer recommended before so we edit the silicon based on customer's need. 0x0C01[2] will also update in 869 revision 3 as well.

May I ask which scenario you want to perform on your side? which link down indication you want to see? Is reading 0x0C01[2] be convenience for you?

--

Regards,

Hillman Lin

Hi Hillman,

If i understood correctly, 0x0001[2] shows "Link Down", when either or both Side loses its link. So when either of the ports has still Link Up, it still shows Link Down meaning that DP83869HM prioritize the Link Down over Link Up for setting 0x0001[2]. Is that correct? It explains why we are still seeing Link Down on 0x0001[2] BUT actually the Link on copper side is actually still UP.

But it then leads to another question. We enable always LLP. Since i could not find any info in the datashet to enable/disable FEF Detection, i assume it is always activated or activated as long as LLP is activated. As soon as LLP is activated, i expect that the DP83869HM should force to drop the link on the copper side, when no energy detected on the SFF transciever. Rev.1 is doing that by detecting energy for 8-10 seconds and drops the link on the copper side. BUT Rev.3 is not doing the same thing as Rev.1. When the LLP is then disabled then it drops the copper link. It is somehow strange that when LLP is disabled, the Rev.3 actually works as LLP enabled and vice versa.

I can not relate the suggested AN with our problem. Since the fiber link detection is working correctly. The problem is that right after Power-On(Boot) without FO cable, why we are still seeing copper side Link UP despite the Fiber Link is Down. Why LLP is not working correctly on the Rev.3 as compared to Rev.1. Why Rev.3 drops the copper link, after disabling the LLP and why not with enabled LLP.

Therefore i asked you whether is it possible that this problem is seen only for some LOT? Since an another user shares the exact same problem, is it possible for you to experiment this with a Rev.3?

Thank you in advance.

Hi Kaya,

Yes, your first understanding is correct. 0x0001[2] will update for both Fiber and Copper link up with one of them drop the link in revision 3

I am not sure if I understand your questions.

• Could you clarify on what "LLP" means?
• If possible, could you clarify on your concern?
• Is the behavior not match with the scenario I talk about earlier?

I don't think it is the concern of LOT since revision 3 of DP83869 could came from different location of fabrication.

--

Regards,

Hillman Lin

Hi Hillman,

i use LLP to refer Link Loss Pass Through. After i did some experiment, i have the following questions to understand whether this is the expected behaviour or not of Rev.3:

1. DP83869 is powered on respectively turned on without any FO cable on SFF transceiver.
2. DP83869HM is configured via MDIO: Auto Negotiation is disabled, Speed:100M, Full Duplex, LLP is enabled and finally SW Restart.
3. LNK LED on Fiber Side is OFF, LNK LED on Copper Side is ON, ACT LED is OFF
4. BMSR(1h) shows that no Link (Bit 2 = 0).
5. Step 3 is actually our concern. Without any valid Link on Fiber Side, We expect that LNK LED on copper side must be OFF due to enabled Link Loss Pass Through. In this case Rev.1 shows correctly that LNK LED on Copper Side is OFF. This is the difference, which concerns us WHY?
6. Sending Ethernet Frames from copper side to DP83869HM: LNK LED on Fiber Side is OFF, LNK LED on copper side is ON, ACT LED flashes.
7. There is no link on the Fiber side. But DP83869HM send frames to SFF transceiver. I checked that the frames going out from SFF are actually the same frames coming into DP83869HM. So why DP83869HM sends out frames via Fiber Side when there is no link or FO cable. All register shows that there is no Link But DP83869HM sends the frame anyway.
8. I disabled LLP(0x01EC: 1FFD) and make SW Restart(0x01).
9. LNK LED on copper side is OFF.
10. Ethernet Frames are not sent via DP83869HM and ACT LED is OFF.
11. I enabled LLP(0x01EC: 1FFC) and make SW Restart(0x01).
12. LNK LED on copper side is ON again.
13. Ethernet Frames are sent via DP83869HM and ACT LED flashes.
14. Step 12&13 actually troubles me. Because enabling/disabling LLP actually reverse the LLP mechanism.
15. As summary: The behaviour of Rev.1 with enabled LLP = The behaviour of Rev.3 with disable LLP for the above case 

Have you ever been faced with same observations of Rev.3 considering the above case? Do you think the behaviour given above is normal? If it is normal and expected, we could mark this post as resolved.

Hi Kaya,

Thank you for the detail explanation. 

Correct if I am wrong. From your observation on revision 1, you also seeing LED link drop and 0x0001[2] lose link when you disconnect the Fiber side without losing link in copper side? After sending the Ethernet Frames on copper side, the link LED and 0x0001[2] is shown link up as well right. You want to double check is this scenario valid for Revision 1?

--

Regards,

Hillman Lin

Hi Kaya,

Thank you for the detail explanation. 

Correct if I am wrong. From your observation on revision 1, you also seeing LED link drop and 0x0001[2] lose link when you disconnect the Fiber side without losing link in copper side? After sending the Ethernet Frames on copper side, the link LED and 0x0001[2] is shown link up as well right. You want to double check is this scenario valid for Revision 1?

If my understanding is correct. Could you also check it with another Rev1 869EVM board and see did you see the similar scenario?

--

Regards,

Hillman Lin

Hi Hillman,

our Concern is not Rev.1 but Rev.3. We have plenty boards with Rev.1 and we think Rev.1 is functioning correctly for this specific case in my last reply and all of them shows the same behavior. Because considering the above case in my last reply, Rev.1 is dropping the copper link, if no link on the fiber side. We believe that this is correct because we enable Link Loss Pass Through.

But for the same specific case, Rev.3 does not drop copper link. We believe that it is not correct. We believe that some design change in Rev.3 causes this unexpected behavior. Because Rev.1 and Rev.3 on the same board shows different behavior for the case in my last reply. If everything is same on our board(HW and SW) except DP83869HM, then the cause of this difference is DP83869HM.

What we simply want to know is that behavior of Rev.3 is familiar to you for the above described case ? How can you explain the behavior of Rev.3 considering this specific case step by step. Could you please look into the given steps in my last reply to see Rev.3 is working correct or not? 

Please remember that our concern is only for the described case in my last reply. After we disable LLP or plug-in/plug-out FO cable, then Rev.3 starts to drop copper link when no link on Fiber side as same as Rev.1

Hi Kaya,

Sorry for the confusion, I think I miss your point on the problem statement. your observation is completely correct. 0x01EC[0] is the register that disable the feature of 0x0001 detection on the fiber side for Rev3. So when you enable link loss feature, Rev3 have the similar situation as Rev.1 on DP83869.

--

Regards,

Hillman Lin

Hi Hillman,

i think, there is still some confusion.

I could not understand what "the feature of 0x0001 detection on the fiber side" means. Do you mean Link detection on the fiber side?

We enable link loss feature in accordance with snla318(page 9) by writing 0x1ffc to register 0x1ec (bit 0 = 0). This register setting will enable the link loss feature according to the datasheet (SNLS614B). 

This register setting is done by SW via MDIO and also RX_CLK (pin 32) is internally pulled down (we do not use external pull down). We are sure that link loss feature is enabled. But as i said before, both revisions of DP83869HM work differently considering my experiment in the previous post as follows:

Rev.1: 8-10 seconds later after power-on, copper link is dropped. This is OK and Expected.

Rev.3: the copper link is not dropped. This is NOT OK and Unexpected.

Since the SW enables Link loss feature for both Revision of DP83869HM, Why the copper side has still link-up on Rev.3?

Rev.3 starts to work same as Rev.1 when i disable the link loss feature or plug in/out the FO cable. 

So when i enable link loss feature on Rev.3 does not give the similar situation on Rev.1

So i have to disable link loss on the Rev.3 to see the same result on the Rev.1.

Hi Kaya,

Sorry if that is confusing. Let move one step back, register 0x0001 is a link status on copper. Our goal for Rev.3 is having this register 0x0001 link status register to detect on both copper side and fiber side. However, some of the customer want this link status indication only detect the copper side. Therefore, we had register 0x01EC to play around with the fiber link (FO cable). But copper link should follow the normal link drop on and off pattern.

0x01EC should not have an effect on the copper side. I will try out the experiment on my side as well.

--

Regards,

Hillman Lin

Hi Hillman,

were you able to try the case, which i mentioned in my previous reply?

<You: 0x01EC should not have an effect on the copper side.> But 0x1ec checks the status of copper and fiber link and when one of them drops, 0x1ec forces the phy to drop another side. From my understanding, it should have an effect on the copper side.

<You: Therefore, we had register 0x01EC to play around with the fiber link (FO cable).> What actually played or changed in this register? Could you briefly explain in which scope this register in Rev.3 differs from Rev.1?

<You: But copper link should follow the normal link drop on and off pattern.> Copper link follows the fiber link after we disable Link Loss Pass Through or plug-in/out FO Cable. If a FO cable is plugged in and DP83869HM powered on, then the copper link also follows fiber link.

I have mentioned that after i plug-in and -out the FO cable, the copper link follows the fiber side. But when i remove the FO cable and make a SW Restart (1F= 4000), then the same problem occurs and copper link stops to follow fiber link (meaning that copper link is up without fiber link).

Hi Kaya,

Sorry for the confusion. If possible, I would like to clarify what is the link status of the following scenario? 

--

Thank you,

Hillman Lin

Hi Hillman,

For the top scenario: Copper Link is Down (Copper Link LED is OFF). The copper link always follows the fiber link.

For the bottom scenario: Copper Link is Up (Copper Link LED is ON). In this scenario, if we plug in and out the FO cable, the copper link is Down. After a SW Restart, the copper link is Up again for No Fiber connection.

Hi Kaya,

One more clarification I would like to ask on my side:

• For both test, have you done soft reset every time you configure it?
• If so, how did you configure the soft reset? write 0x001F to 4000?
• What is the scenario of the two case above after you write soft reset?

Thank you for your patience

--

Thank you,

Hillman Lin

Hi Hillman,

• Yes, every time we configure the PHY via MDIO, we perform SW Restart at the end. I also perform SW Restart, when i play(enable/disable) with Link Loss Through(indirect access to extended register space) each time.
• Yes i write 0x4000 into 0x001F to reset PHY circuitry.
• I suppose you refer the two scenarios you made visually:
  • For the top scenario, when the link loss is disabled, SW Restart plays no role. The copper side link is always down after some time and always follows the fiber link after each SW Restart.
  • For the bottom scenario, when the link loss is enabled, I have made two experiments:
    • First experiment:
      1. the copper link is up after power-on.
      2. FO cable is plugged in and out.
      3. the copper link is down
      4. SW Restart is performed
      5. the copper link is up
    • Second experiment:
      1. the copper link is up after power-on.
      2. FO cable is plugged in and out.
      3. the copper link is down
      4. FO cable is plugged in
      5. the copper link is up
      6. FO cable is plugged out
      7. the copper link is down
      8. SW Restart is performed
      9. the copper link is up
    • For the bottom scenario, when i power-on the REV.3 with fiber link(FO cable is inserted), the copper link always follow the fiber link.If i remove the FO  cable, then the copper link is down too. But after SW Restart, then the copper link is up again for no fiber connection.

Hi Kaya,

I will discuss with the team and provide you a response by tomorrow. Thank you for your patience.

--

Thank you,

Hillman Lin

Hi Kaya,

Thank you for your clear explanation. Everything is clear now. If possible, could you perform one more test on your side?

• Check register 0x01EC before and after the SW restart? Could you double check if the value are the same before and after the SW reset. From our understanding the value of 0x01EC should not change after the SW reset (software reset)
• One more thing I would like to confirm on my side is you are writing register 0x001F to 4000 instead of pulling the reset pin low or writing 0x001F to 8000 when you are performing the SW reset (software reset) right?

I will perform a test on my side to confirm if we are able to see the same observation.

--

Thank you,

Hillman Lin

Hi Hillman,

• Before and After the SW Restart (Write 0x4000 to register 1Fh), 0x01EC is not changed.
• SW Reset (Write 0x8000 to register 1Fh) sets 0x01EC to default(reset) value (0x01FFD).
• SW Restart does not change 0x1EC, but SW Reset clears the 0x1EC register and sets to its reset value
• I do not perform SW Reset (Write 0x8000 to register 1Fh), since it clears all registers and deletes our register configuration. The datasheet recommends SW Restart(Write 0x4000 to register 1Fh) after all register configuration, this is also what i do at the end.

The 0x01EC shows correct value of 0x1FFC(Link Loss Pass Enabled) after we configure DP83869HM and SW Restart. But the PHY behaves as 0x01EC = 0x1FFD (Link Loss Pass Disabled).

The table above shows our observation, when no FO cable is inserted into Transceiver after the register configuration and SW Restart. Both Revision work inversely considering the Link Loss Pass Through Mechanism.

To make Rev.3 works as Rev.1 (as given in Table above),

• Link Loss Pass Through must be disabled or
• FO cable must be plugged in/out

Hi Kaya,

Thank you for the information.

 If possible, could you read the register 0x0001, 0x01EC, and 0x0C01 three times for each test? (I am concerning some of the register is latch low where it keep the previous link status)

1. Power up Rev.3 without any configuration with both Fiber and Copper plug in
2. Unplug the Fiber cable
3. Soft reset
4. program 0x01EC = 1FFC
5. Soft reset
6. plug fiber cable back
7. Unplug the fiber cable

--

Thank you,

Hillman Lin

Hi Hillman,

as you requested below are the REV.3 register values for each step in your previous reply:

1. 0x0001 = 0x796D(3 times)  | 0x01EC = 0x1FFD(3 times) | 0x0C01 = 0x6149(1st read), 0x614D(2nd and 3rd read)
2. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFD(3 times)  | 0x0C01 = 0x6149(3 times)
3. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFD(3 times)  | 0x0C01 = 0x6149(3 times)
4. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x6149(3 times)
5. 0x0001 = 0x7969(3 times)  | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x6149(3 times)
6. 0x0001 = 0x796D(3 times) | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x614D(3 times)
7. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x6149(3 times)

I also perform these steps for REV.1 for you to compare both revisions:

1. 0x0001 = 0x796D(3 times)  | 0x01EC = 0x1FFD(3 times) | 0x0C01 = 0x6149(1st read), 0x614D(2nd and 3rd read)
2. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFD(3 times)  | 0x0C01 = 0x6149(3 times)
3. 0x0001 = 0x7969(3 times)  | 0x01EC = 0x1FFD(3 times)  | 0x0C01 = 0x6149(3 times)
4. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x6149(3 times)
5. 0x0001 = 0x7969(3 times)  | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x6149(3 times)
6. 0x0001 = 0x7949(1st read), 0x796D(2nd and 3rd read) | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x614D(3 times)
7. 0x0001 = 0x7949(3 times)  | 0x01EC = 0x1FFC(3 times)  | 0x0C01 = 0x6149(3 times)

You have also mentioned that you will replicate the test on your side. Did you observe anything strange concerning Link Loss Pass through?

If this is an expected and designed behavior of REV.3, we are gonna mention about this behavior in user manual of the board. What we need is that a confirmation from your side that what we observed is correct and we do not need to do anything to overcome this issue.

Hi Kaya,

Sorry for the late reply. We seeing the similar observation between Rev.1 and Rev.3 of DP83869PHY. The observation you see are similar with our observation. The link status depend on fiber status. The link will drop when fiber is disconnected, the link will recover when fiber is connected back.

--

Regards,

Hillman Lin