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: DP83869 in RGMII-SGMII mode does not work at 100M

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869
Our project uses the DP83869 chip in RGMII-SGMII mode. The block diagram is shown in the figure.
The RGMII interface is connected to the MAC of the LS1027 (NXP) processor.
The SGMII interface is connected to the VSC8552 chip (PHY MICROCHIP). We were unable to get the DP83869 to work in Autonegotation mode.
We took the advice from (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/911770/dp83869hm-bridge-rgmii-to-sgmii-mac-to-mac-configuration/3385960?tisearch=e2e-sitesearch&keymatch=DP83869%2520RGMII%2520to%2520SGMII#3385960).
We have written to the register REG(0xC00) = 0x0140. After that, the above block diagram started working in 1G mode. Throughput tests at 1G pass without comment. Now we needed to conduct similar tests in 100M mode. To do this, write to the register REG (0xC00) = 0x2100.
However, the Ethernet packets are not getting through. All necessary signals are present on the RGMII DP83869 interface pins. Activity is visible on the RX_D[0:3], RX_CTRL/RX_DV lines. There is a 25MHz clock signal on the RX_CLK pin.
However, the ethtool utility (which is running on the LS1027 processor) shows that fragmented frames are arriving on the MAC interface. manipulations with the fields DLL_RX_DELAY_CTRL_SL and DLL_TX_DELAY_CTRL_SL of the ANA_RGMII_DLL_CTRL Register (Address = 0x86) do not change the situation.
Has the DP83869 been configur
ed correctly?
  • Hello,

    If the bridge works at 1G, then there shouldn't be any issues with 100mbps. It would seem to be a configuration to enable rather than modifications of RGMII clock timing. Have you tried extending SGMII auto-negotiation 0x31[6:5]?

    Sincerely,

    Gerome

  • Hello Gerome!

    We changed the register bits 0x31[6:5] = 11, but this did not lead to the desired result. Performed Restart 1000BASE-X/SGMII Auto-Negotiation Process 0xc00[9] = 1, but that didn't help either.

    BR

    Andrey

  • Hi Andrey,

    Can you verify that the VSC PHY is running at 100mbps speed too? If VSC PHY is at 1G while bridge is at 100mbps, this could explain why you see fragmented packets. Can you also verify that DP83869 RX_CLK is changing from 1G setup and 100mbps setup?

    Sincerely,

    Gerome

  • Hello, Gerome!

    Since we are using the non-autonegotiation mode, we change the bridge settings by writing to the corresponding register. For 1G register 0xC00=0x0140, for 100M 0xC00=0x2100. In accordance with this, RX_CLK changes. At 1G RX_CLK = 125MHz, at 100M RX_CLK = 25MHz. PHY operates in 100M mode. I achieve this by setting the interface speed on the computer that is connected to our 100M port. When observing with an oscilloscope on the RGMII interface at 100M, no artifacts are observed. The waveforms look quite good. There are also no very short frames on the RX_DV line.

    BR

    Abdrey

  • Hi Andrey,

    To confirm, you have a separate 1G port vs 100mbps port? Is it possible to confirm via registers on VSC PHY that it is operating at 100mbps and 1G during their respective setups? Also to confirm, you do have 100nF capacitors between DP83869 and VSC PHY?

    Some tests you can try to isolate potential problem areas. Please let me know result.

    Can you also try a transmit only packet test, where LS sends data out via DP83869 and VSC PHY out to link partner and respective MAC? 

    Another test you can try is placing DP83869 into MII Loopback (Reg 0x0[14]). LS sends packets out, it will be looped back at DP83869 MII and relayed back to LS. LS can then compare for any issues.

    Sincerely,

    Gerome

  • Hello, Gerome!

    Good afternoon! I will inform you about the intermediate results that we have achieved today. We managed to achieve that the system shown in the figure worked in the auto-negotiation mode. Analyzing the VSC8552 PHY registers, we found that we had autonegotiation disabled on the SGMII interface. After turning it on and writing to the bridge register DP83869 0xC00 = 0x1140, the system from MAC LS1027<->DP83869<->VSC8552 started working in auto-negotiation mode. Changing the speed on the computer port 10M, 100M, 1G, which is connected to our port directly with a cable, we also see a change in speed on the RGMII interface. Ethernet frames pass without problems at speeds of 10M and 1G. At 100M, Ethernet frames do not pass, and fragmented frames are also visible.

    I will test your loop idea in the morning and get back to you.

    BR

    Andrey

  • Hello, Gerome!

    Your recommendations for installing a loopback could not be implemented.

    The loopback is not enabled by setting the Reg 0x0000[14] bit. We managed to enable the loopback on the MAC interface by setting the Reg 0xC00[14] bit. In this case, the value recorded in Reg 0xC00 = 0x5140. The speed on the interface is set to 100M. Launched ping on LS1027 towards the interface. At the RGMII interface, the TX_CTRL/TX_EN and RX_CTRL/RX_DV signals were monitored. They were synchronous and shifted relative to each other by several cycles. This indicates that the loop at the MAC level of the DP83869 has been turned on. Next, we controlled the statistics on and interface using the ethtool utility. There are no errors. The counters of sent and received packets are the same. All received packets are valid. This experiment confirms that there are no problems between the MAC layers of LS1027 and DP83869.

    Where should we look next?

    BR

    Andrey

  • Hello,

    Gerome is currently on vacation. Please expect a response next week. Thank you for your understanding.

    Sincerely,

    David

  • Hi Andrey,

    It appears that through this testing, the issue does not reside with DP83869. I would advise taking a look at the other devices (VSC and LS) and contacting their respective supports for isolating the issue further. 

    Sincerely,

    Gerome

  • Hello, Gerome!

    We have solved the problem.

    Now our system works in auto-negotiation mode at speeds of 10M, 100M, 1G. To do this, we needed to enable the option in PHY VSC8552 - "If both the first two nibbles of the 10/100 packet are not 0x5, a byte of 0x55 must be prefixed to the output. An additional byte of 0x55 must be prefixed to the output if the next two nibbles are also not 0x5."

    Thank you for your help.

    BR

    Andrey