DP83822HF: The Linkup Status of the Basic Mode Status Register (BMSR) may be Valid at random even though the SFP module is not inserted.

Hi,

This is a large bit of information, please correct me wrong if I am misinterpreting the problem statement.

DP83822 is in a fiber application on a PCB where it is connected to a fiber case/connector with the actual SFP module unplugged. Power is applied to the case after the PHY is up, and somehow the PHY is detecting a pseudo linkup.

Probing the line yields figures 1 and 2 with the latter being a later time behavior of the line (RX+). When probing the line, the behavior is not realized. When connected to GND, this behavior is also not realized. So the hypothesis is somehow the line is being biased in such a state undetectable with scope to give PHY a pseudo-good link indication.

Questions: 

1) Is this happening on many boards? Or is this happening on single board 70-80% of the time?

2) I noticed that PHY is being help into reset in the scope shots. Wouldn't link not be achievable in this scenario?

3) When 3.3V is being applied into the system (in your words, to the SFP case), is the PHY also being powered on at the same time?

4) Whenever trying to read link up in FX application, PHY needs to be soft restarted (0x1F = 0x4000). Is this pseudo link up still present afterwards?

Comments:

1) MDI termination looks fine.

Sincerely,

Gerome

Hi, thanks for replay.

Your problem statement is correct.

> 1) Is this happening on many boards? Or is this happening on single board 70-80% of the time?

　Happened many board.

　A board has a one-to-one connection between three SFP modules and the PHY,

   but the SFP modules that occur are also random and occur about 30% of the time.

> 2) I noticed that PHY is being help into reset in the scope shots. Wouldn't link not be achievable in this scenario?

   The waveform is the same as when Reset is performed, but the LED will light only after Reset is released.
   After about 8 seconds after 3.3VON, the reset will be released, and the LED will light up within about 1 minute.

> 3) When 3.3V is being applied into the system (in your words, to the SFP case), is the PHY also being powered on at the same time?

  3.3 V is common to all, and is supplied to the case of the PHY and the optical module, and is turned ON simultaneously.

> 4) Whenever trying to read link up in FX application, PHY needs to be soft restarted (0x1F = 0x4000). Is this pseudo link up still present afterwards?

  Even if you run DigitalRestart with 0x1F=0x4000, the LED will light up again in about 1 minute.

The most important thing to check is the LinkUp condition below.
My guess is that it will LinkUp when the RD signal fluctuates. Is that correct?
If this guess is not correct, please tell me the combination of signals that will allow the link up.

> (3) In the first place, what are the conditions under which the Linkup Status becomes Valid in the 100BASE-FX condition for DP83822HF?
>      If the RD_P/RD_N signal fluctuates, is it valid?
>     Or is it not just a fluctuation but a valid once the negotiation is completed?

Best regards.

Hi.

I found the following FAQ on this forum.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1272949/faq-dp83822if-fiber-link-status?tisearch=e2e-sitesearch&keymatch=DP83822HF

It was interpreted that the LinkStatus must be reset before it can be read successfully.
This could be interpreted as saying that LinkStatus itself is unstable, leading to this incident.
Also, does Reset only apply to SoftReset? Can I use DigitalRestart?

I would like to receive an answer as soon as possible based on the customer's request (due date).

Best regards.

Hello,

This is why I had asked if the behavior was still present after applying a restart of the PHY. 

An experiment I would like to suggest is to remove the DC blocking capacitors. This would cause a direct connection between the PHY and cage and help isolate whether the issue lie in the PHY system, or in the fiber cage system as there is also components there which may be contributing to the unexpected behavior.

Sincerely,

Gerome

Hi.

>An experiment I would like to suggest is to remove the DC blocking capacitors.

This experiment has been conducted. (Exp2)
I tried the following pattern, but it didn't improve everything.(Linkup and LED on)

I simply want an answer to the Linkup condition I am asking.

We can guess which of the following is applicable?
 (1) LinkUp when RD signal fluctuates
 (2) LinkUp when negotiation with the opposing machine is completed
 (3) If the RD signal does not change for a certain period of time, LinkUp
 (4) Other than that

Hi Kondo,

This is a very unexpected result, and thus don't understand why the PHY is linking up in this state. To fully rule out the PHY, I suggest the following two experiments:

1) Disconnect DC blocking caps and NOT short across. This would isolate the PHY from the case, and if the issue goes away, it may warrant taking a look at the case vendor.

2) With normal setup, toggle 0xA[14] and restart the PHY via 0x1F = 0x4000. This would put the PHY into copper mode and see if there is something unexpected going on in the PHY.

Sincerely,

Gerome

HI.

>1) Disconnect DC blocking caps and NOT short across

　It takes time and effort to prepare for the exam, so we ask that it be conducted separately.

>2) With normal setup, toggle 0xA[14] and restart the PHY via 0x1F = 0x4000

　If bit14 is 0, the problem will not occur.
　Then, when bit14 was changed back to 1, the problem occurred.
　It remained dependent on bit14 status after DigitalRestart.

I understand that you think the cause is our circuit design and SFP case and connector.
However, why can't I get an answer on the condition that LinkStatus changes, which I have been asking for a while?
This condition is only for DP83822, so it should be considered separately from our circuit design.
Or is there an inherent problem with using it in Fiber mode, like the information in the FAQ?

　FAQ:https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1272949/faq-dp83822if-fiber-link-status?tisearch=e2e-sitesearch&keymatch=DP83822HF

Hi Kondo,

As this is an unexpected behavior of the PHY, we do not have much data as to what signals may cause this pseudo-link up. The best course of action is to understand potential sources and look to mitigate them to prevent such an event. As there is no auto-negotiation, item 2 might be ruled out. We have done FX testing on our DP83822 EVM and have not seen such behavior. Thus we have reason to suspect marginality in the design related to the SFP connector.

Sincerely,

Gerome