DP83822HF: Can signal detection feature (SD_EN) be enabled through register configuration?

Hi John!

I understand the concern here, but there isn't a way to enable Signal Detect via the registers. Could I ask why the customer wants to enable SD?

There is an FAQ available for checking Fiber Link Status on the DP83822. This might help with your current issue. 

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1272949/faq-dp83822if-fiber-link-status

Regards,

Alvaro

Hi ALvaro,

Thank you for reply.

It is due to they want to use Force Link mode (100BASE-FX). Previously Tier told them to use Force Link mode they should disable SD function. However they found some other issues occured once SD function is disabled and use Force Link mode: the phy cannot rebuilt 100BASE-FX link once filber is plug-off and plug in again. So they want to resume the old design.

Regards,

John

Hi John,

The DP83822 has an issue with updating the link status in Fiber mode, as described in the link in my previous reply (pasted below again for convenience).

When testing this out, can we check the link status of the Link-Partner? I have done this test with the following setup:

DP83822EVM <-- Fiber Cable --> Link Partner

When I would disconnect and reconnect the fiber cable, the DP83822 would not indicate link has recovered, but the link partner does. Link is actually up but the status bit within the DP8322 doesn't reflect it. The work around is mentioned in the FAQ: before checking the link status perform a Soft-Reset (Reg 0x1F = 0x4000).

Enabling SD will NOT resolve this issue. SD will work as expected, indicating link or not, but the PHY will not know, i.e. it will not reflect in the register link status.

I hope this clears up the issue.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1272949/faq-dp83822if-fiber-link-status

Regards,

Alvaro

Hi Alvaro,

Thank you for your information.

However the case you mentioned seems not match what my customer experienced. My customer operated PHY in force 100Mbps link mode through register 0x0040 Bit 13, so in fact their system ignore the link status bit in force link mode. While they found their system cannot send data after fiber is pulled out and on again.

Additionally, if they resume normal condition (non-force link mode) they found very high packet loss rate, about 10%. Is this high loss rate issue due to disabled SD function?

If SD function has been disabled through pin strap, can link status bit be updated through soft reset?

Thank you!

John

Hi John

John11513 said:

My customer operated PHY in force 100Mbps link mode through register 0x0040 Bit 13

Understood, is there a reason for this requirement? Normally I would recommend forcing speed by keep Auto-Negotiation on and de-advertising 10M speeds in Reg 0x4. This would have the DP83822 only operate in 100M. Is fiber being enabled via strap or register write (Reg 0xA[14] enables fiber)?

John11513 said:

Additionally, if they resume normal condition (non-force link mode) they found very high packet loss rate, about 10%. Is this high loss rate issue due to disabled SD function?

I don't think so. In lab I have two different EVMs, one with SD connected and the other without. Both are able to link up and transmit data flawlessly.

John11513 said:

If SD function has been disabled through pin strap, can link status bit be updated through soft reset?

Yes! Try setting Reg 0x1F = 4000, then read Reg 0x1. Please let me know if this works in the customer's board.

Regards,

Alvaro

Hi Alvaro,

Thank you for your detailed explain.

1. Why use force link mode?

This is a special requirement from Chinese GI market. End user requires some critical equipment should be able to send out data even with single TX fiber.

Surely fiber mode has been enabled. The communication is correct first time the device is configured into force link mode. The problem is it cannot send out data anymore once the fiber is plug out and in again.

2. Do you mean the device can implement signal detection function even if you disable this function through pin strap?

Regards,

John

Hi John,

Understood with the forced mode. The problem remains that data does not transmit once the cable is unplugged and plugged back in right? Have you tried Reg 0x1F = 4000 then reading Reg 0x1? What does Reg 0x1 say about the current link status?

John11513 said:

Do you mean the device can implement signal detection function even if you disable this function through pin strap?

No, I'm afraid that this needs to be enabled via straps.

Regards,

Alvaro

Hi Alvaro,

Thank you for confirm. 

Yes correct. The problem is PHY cannot transmit data once the cable is unplugged and plugged back in force link mode. Is the wrong link status bit may result such problem? My understanding is the force link mode may ignore the link status bit. Customer does not try soft reset yet. However the current design has disabled the SD function I am afraid soft reset will not work if the link status bit may result such problem.

Thank you!

John

You're welcome John,

Is this issue closed? Could you let me know the result once the customer tries the soft reset?

Regards,

Alvaro

Hi Alvaro,

Engineer told me they had tested soft reset, cannot solve the problem. (SD function has been disabled through pin strap according to Tier's proposal.) And the device can only resume communication after cycling power supply (power off and on again). 

This is an important and has pending long time. If we can help them solve the problem it will be great.

Thank you and Best Regards,

John

Hi John,

I went into lab with a DP83822EVM and forced 100-FX link by setting Reg 0x40 = E11D (default value was C11D).

The PHY behaved as expected, with the Link LED & Reg 0x01 saying valid link, regardless if the cable was connected or not. To check the link status I had to look at the link-partner, who's link LED would turn on and off as expected with the cable plug/unplug. 

To verify your setup, could we try an experiment where we do NOT force link?

1. See if valid communication is possible
   
   1. Read Reg 0x1 to confirm link status
2. Unplug the cable
3. Set Reg 0x1F = 4000
4. Read Reg 0x1
   • The Link bit should be low, since the cable is unplugged
5. Plug the cable back in
6. Repeat Step 3 & 4
   1. This time we expect the link status to be high again
7. See if valid communication is possible
   1. I understand that this is the "Normal" Case and that this was tried before with high packet loss.
      1. This case should be resolved first, it is not because of Signal Detect. This could be a schematic or layout issue

Regards,

Alvaro

Hi Alvaro,

Thank you for test. Please let me know, how did you configure the SD_EN function? (is the signal detection function is enabled or disabled in your test?)

Regards,

John 

Hi Alvaro,

Here is the feedback from engineer:

1) The wrong status was not occured everytime after plug-in and out filber, you need multitimes of plug-in and out operation to make the device into fault conditions.

2) Once the device is in fault condition, it may report increased 'False Carrier Event Counter' (in 0x0014 register) and 'Receive Error Counter' (in 0x0015 register). And also it reported 'RMII Overflow Status' in 0x0017 register.

Could you please check if you can replay the phenominen?

I have asked engineer do the test you said, however recently engineer is busy on other projects. They need some more time to do the test.

Thank you!

John

Hi Alvaro,

Considerting the signal detection function has been disabled in current design, I think they cannot read correct link status through step 3 & 4. Should they enable the SD function before the test?

Thank you!

John

Hi Alvaro,

I just got feedback from engineer. In fact they did test normal mode (non force link mode) before. The communication is always correct no matter how many times of plug-out and in fiber.  They do not think there are any problem with normal mode and hardware design.

Thank you!

John

Hi John,

Forgive me I thought I mentioned it in my previous reply but I didn't. The board I was using did NOT have signal detect enabled.

You have confirmed that the test case I proposed works in normal conditions on your end correct? However the issue remains when using Forced Link, communication never recovers after a cable disconnect. 

Please reach out to me via email to set up a meeting with the customer.

Regards,

Alvaro