DP83869HM: Ping test blink led but fail.

Hi Nicolas,

I have a couple questions:

1. We have a fiber debug guide that I recommend reading through. The FEF error suggests some issue with the fiber interface, however I am interested in how the BIST test was performed. By 'looping the TX/RX slot of the SFP module' do you mean the SFP module has a loopback mode that connects these paths together, or are you soldering the lines together with a wire?

2. Do you have a DP83869EVM to test with? This is a known-good platform that can be placed into reverse loopback to perform BIST PRBS testing over the MDI. 

3. When you ping, are you seeing a refusal to identify the host (host unreachable) or are you able to ping the host but with packet loss?

4. Have you performed any uni-directional testing? Ping testing will use both the TX and RX path on the interface, but there are throughput tests (like iperf3) that can send data one way or the other. Can you try sending data from the STM32 to the linux PC and see if you can get packets through, then reverse the direction by sending from the linux PC to the STM32? This would tell us if one path or the other specifically is failing.

To answer your question

Nicolas Bouquet said:

is it normal that the nIRQ is stalled at 0 ?

If the INT_N pin is constantly low, make sure there is an external pullup on this line and that the MAC is not holding this line low. If these are not the case and it is still held low, the PHY is sending an interrupt on the pin due to one of the enabled interrupt conditions. The interrupt register needs to be read in order to clear this condition.

Best,

Shane

Finally, no, my issue is not resolved...

I also have a LVDS screen on the PCB: the link is OK only when the screen is not plugged. I'm working on it since 3 days... The screen itself is not the responsible, but the DC/DC powering the screen is involved. There is a dedicated 2.7V buck for display logic (LMR54406) and a +16V boost for backlight (TPS923650)

The following tests are without the screen, with the MP2 and PC continuously pinging themselves.

- 2.7V DC/DC unloaded: link OK

- DC/DC slighly loaded : link OK

- DC/DC with nominal load (300..400mA) : link KO (but the Tx activity LED is still blinking)

Removing the load makes the link instantly OK

When loading the LMR54406, there is some spikes on the power line when its internal MOS switches ON and OFF. Theses spikes are polluting all the board. Applying the same load on any other DC/DC does not generate any particular noise (I have 3 others regs : 3.3V, 3.7V, 1.7V, based on LMR64410/LMR43606 devices). Same power decoupling and routing techniques are applied for all DC/DC). I'm not able to simulate the LMR54406 : webench simulation is failing. Same with LTspice.

Using a differential probe, I can see a clean signal on the SFP output, independently of the DC/DC load, so, no, the SFP module seems to not be perturbed by the DC/DC noise (and its LOS output is still 0 - yes there is a pull-up, the signal goes to 1 when disconnecting the fiber).  

The 25MHz clock is still fine.

...But the DP83869 loose the signal.

An important note is that the SFP output signal is 62.5MHz (125Mbps ?), I don't know what type of modulation is used but I was expecting a multiple of 100MHz (the DP SOP signal is also 62.5MHz so this is probably fine).

"If the INT_N pin is constantly low, make sure there is an external pullup on this line and that the MAC is not holding this line low. If these are not the case and it is still held low, the PHY is sending an interrupt on the pin due to one of the enabled interrupt conditions. The interrupt register needs to be read in order to clear this condition."
=> Yes, there is a RPU (signal is sometime high when linux is booting), but no, even when manually reading the IRQ reg, IRQ line is still 0:

mdio st* mmd-c22 0:31 raw 0xC19

About the INT_N pin, I found why it is stucked at 0

I have a bug in my driver, it does not read FX_INT_STS @ 0xC19, and it does not read INTERRUPT_STATUS @ 0x13, explaining 2 issues:

- FX_INT_STS was not 0 when reading it manually (because the driver did never read it)

- INT_N does not goes back to 1 after a manual read of FX_INT_STS (because it is also associated to INTERRUPT_STATUS)

Writing 0 to INTERRUPT_MASK and reading FX_INT_STS  when the INT_N fall to 0 make the interrupt scheme working normally. 

According to my understanding, INTERRUPT_STATUS is only reporting things about ETH. In fiber mode, it does not give any more useful information than FX_INT_STS and can be masked/ignored. Do you confirm?

Hi Nicolas,

As noted in the datasheet, both interrupt registers must be read to clear pending interrupts:

If you don't need any interrupts from the INTERRUPT_STATUS register you can disable these interrupts via masking, however the register may still need to be read to clear an active interrupt.

For the power network it seems like the DC/DC is generating noise on the power line that interferes with the devices on your board. Improving the power decoupling/damping network or swapping to a less noisy source would be my recommendation

Best,

Shane

The power source is a battery. The noise source is clearly the LMR that is generating definitely more noise than expected.

About the interrupt cleaning... We are using the official driver 

https://github.com/torvalds/linux/blob/master/drivers/net/phy/dp83869.c

(written by Dan Murphy from ti ;)

The interrupt handling function is only reading one register (INTERRUPT_STATUS).  FX_INT_STS is symply ignored. This tends to suggest that the driver has not been tested in fiber mode.

Hi Nicolas,

Our current PHY drivers can be found at this link: https://github.com/TexasInstruments/ti-ethernet-software/blob/main/linux_drivers/dp83869.c

I'll check with my team to see if interrupts are handled appropriately in fiber mode through the driver.

Best,

Shane

The feedback I'm getting is that the driver does not check for fiber interrupts, and it seems like you are able to see this as well. The 0x13 interrupt status register should be read through the driver, though let me know if this is not working.

Best,

Shane