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.

DP83826I: Link established but ping fails (in Basic Mode)

Part Number: DP83826I

Tool/software:

Hello,

We are using the PHY device DP83826I (in Basic mode) with the processor through MII interface in our hardware board design. The block diagram and schematic is attached for your reference.

Schematic_DP83826I_27NOV2024.pdf

We have configured the PHY device, DP83826I in the MII MAC mode using the strap pins. So, we have probed RX_CLK, TX_CLK pins using oscilloscope and observed a perfect 25MHZ clock signal on these pins.

The register dump from 00h to 3fh and register values of 467h, 468h is attached below for your kind reference.

The strap pins in the schematic is same as per the data stored in the register 0x467h (mentioned in the register dump).

"Broadcom XGS IProc Ethernet driver 0.1
bcm_xgs_eth_init enter
Initializing GMAC1
gmac_mac_init: Chip ID: 0xb260
Connect bcm_xgs_gmac-1 to Generic PHY
bcm_xgs_gmac-1 ethernet functionality initialized
eth0: bcm_xgs_gmac-0, eth1: bcm_xgs_gmac-1 [PRIME]
u-boot> mdio list
bcm_xgs_gmac-0:
bcm_xgs_gmac-1:
1 - Generic PHY <--> bcm_xgs_gmac-1
u-boot> mii info
PHY 0x01: OUI = 0x80028, Model = 0x11, Rev = 0x01, 100baseT, FDX
PHY 0x18: OUI = 0x180361, Model = 0x19, Rev = 0x05,  10baseT, HDX
u-boot> mii read 0x1 0-3f
addr=01 reg=00 data=3100
addr=01 reg=01 data=786D
addr=01 reg=02 data=2000
addr=01 reg=03 data=A111
addr=01 reg=04 data=01E1
addr=01 reg=05 data=CDE1
addr=01 reg=06 data=000F
addr=01 reg=07 data=2001
addr=01 reg=08 data=0000
addr=01 reg=09 data=0000
addr=01 reg=0a data=0102
addr=01 reg=0b data=0009
addr=01 reg=0c data=0000
addr=01 reg=0d data=0000
addr=01 reg=0e data=0000
addr=01 reg=0f data=0000
addr=01 reg=10 data=0015
addr=01 reg=11 data=010B
addr=01 reg=12 data=6400
addr=01 reg=13 data=2800
addr=01 reg=14 data=0000
addr=01 reg=15 data=0000
addr=01 reg=16 data=0100
addr=01 reg=17 data=0049
addr=01 reg=18 data=0400
addr=01 reg=19 data=8C01
addr=01 reg=1a data=0000
addr=01 reg=1b data=007D
addr=01 reg=1c data=05EE
addr=01 reg=1d data=0000
addr=01 reg=1e data=0102
addr=01 reg=1f data=0000
addr=01 reg=20 data=3100
addr=01 reg=21 data=786D
addr=01 reg=22 data=2000
addr=01 reg=23 data=A111
addr=01 reg=24 data=01E1
addr=01 reg=25 data=CDE1
addr=01 reg=26 data=000D
addr=01 reg=27 data=2001
addr=01 reg=28 data=0000
addr=01 reg=29 data=0000
addr=01 reg=2a data=0102
addr=01 reg=2b data=0009
addr=01 reg=2c data=0000
addr=01 reg=2d data=0000
addr=01 reg=2e data=0000
addr=01 reg=2f data=0000
addr=01 reg=30 data=0615
addr=01 reg=31 data=010B
addr=01 reg=32 data=0000
addr=01 reg=33 data=0000
addr=01 reg=34 data=0000
addr=01 reg=35 data=0000
addr=01 reg=36 data=0100
addr=01 reg=37 data=0041
addr=01 reg=38 data=0400
addr=01 reg=39 data=8C01
addr=01 reg=3a data=0000
addr=01 reg=3b data=007D
addr=01 reg=3c data=05EE
addr=01 reg=3d data=0000
addr=01 reg=3e data=0102
addr=01 reg=3f data=0000"
"u-boot> mii write 0x1 0xd 0x1f
u-boot> mii write 0x1 0xe 0x467
u-boot> mii write 0x1 0xd 0x401f
u-boot> mii read 0x1 0xe        
0086
u-boot> mii write 0x1 0xd 0x1f  
u-boot> mii write 0x1 0xe 0x468 
u-boot> mii write 0x1 0xd 0x401f
u-boot> mii read 0x1 0xe        
0187"

# PRBS Check using BIST Control Register (0x16h)

We have also done PRBS testing using BIST Control register (0x16h) by connecting a RJ45 cable to the RJ45 connector of the PHY and shorted TX and RX of the RJ45 cable and checked the register 0x16h and as per our understanding, it is working fine. Register dump of the same is also attached.

u-boot> mii info           
PHY 0x01: OUI = 0x80028, Model = 0x11, Rev = 0x01, 100baseT, FDX
PHY 0x18: OUI = 0x180361, Model = 0x19, Rev = 0x05,  10baseT, HDX
u-boot> mii read 0x1 0x16 1
0100
u-boot> mii write 0x1 0x16 0x3100
u-boot> mii read 0x1 0x16 1      
3B00
u-boot> mii read 0x1 0x16 1
3B00

The main problem arises whenever we connect our Hardware board with the external PCB, the link established but ping always fail.

Please let us know the reason for this ping failure.

Regards,
Santosh

  • Hi Santosh, 

    Thank you for the detailed explanation of your setup. 

    with the external PCB, the link established but ping always fail

    Have you tried a ping operation from a PC as a link partner? Do you observe the same issue?

    Checking the registers, I can verify that the PHY is set for using MII, as you mentioned, and that there is a link detected. 

    Since we can see that the MDI link is successful, I suspect that the issue is because of the MII connection to the MAC interface.

    We can try a MII loopback to confirm this. This can be enabled through the register 0x00[14], 0x16[4:0]. Using this, we can send a specific amount of packets from the MAC, which should be routed back to the MAC through the MII interface. Then we can verify packet loss by making sure the number of packets received is the same as the number transmitted.

    Similarly, we can try doing a reverse loopback, enabled through register 0x16[4:0] which would validate everything except the MII lines.

    These 2 tests should help us narrow down the issue to the MII connection, or tell us that the MII connections are good, in which case we can look at other options.

    Best,

    Vivaan

  • Dear Vivaan,

    Thank you for your response.

    Apologies for the typing error in my earlier communication. We have conducted the ping operation using a PC as the link partner (not the PCB). While the link was successfully established, the ping operation consistently failed when connected to the PC.

    Our processor’s MII interface (MAC side) does not have COL and CRS signal pins. Therefore, the COL and CRS pins of the PHY (DP83826I) are used only for the strap configuration. Would this configuration be acceptable ? Please comment on this.

    Additionally, we performed Reverse Loopback testing with the following setup (refer to the block diagram below):

    • Equipment used: Ethernet analyzer set to 100 Mbps speed.
    • Connections: The analyzer was connected to the RJ45 jack (with magnetics), which was in turn connected to the DP83826I PHY.
    • Configuration:
      • The default value of the register 0x16h is 0100h.
      • For reverse loopback, we modified this register to 0110h.

    Observations:

    • Packets were received on the Ethernet analyzer only when the PHY was set to reverse loopback mode (0110h).
    • In the default mode (0100h), no packets were received on the analyzer.

    Please confirm if we have conducted the Reverse Loopback testing correctly, or are there any issues with our test setup ? This will help us to proceed with the MII loopback testing.

    Looking forward to your valuable comments and suggestions.

    Best regards,
    Santosh

  • Hi Santosh, 

    Our processor’s MII interface (MAC side) does not have COL and CRS signal pins

    This is very unusual. For MII interface, CRS and COL pins are a requirement laid out in the IEEE standard. Can you verify again if the MAC is using MII or RMII interface. The RMII interface does not require CRS/COL pins but instead CRS_DV. 

    Thank you for conducting the reverse loopback test.

    You have conducted the test correctly. We can see that the packets are being routed back to the analyzer after loopback is activated. This is what we expect to see, and it validated most the the PHYs datapath, up until the MII interface. There seem to be no issues here, so the problem must exist within the MII interface, like we first thought. 

    Do keep me updated with the MII loopback testing, which should confirm that the MII interface is not functioning properly. 

    Best,

    Vivaan