I am debugging a design with Intel socfpga MAC connected to DP83867IRRGZ PHY (RGMII interface). My problem is that ping messages from the target HW (u-boot and linux net drivers) are not seen on the ethernet line (using wireshark running on host PC). The MII interface seems to be working correctly. When connecting to a host PC the ethernet link is automatically established (autoneg) and remains connected. The PHY ACT LED blinks correctly with each ping request being sent from target HW (also blinks when ping sent from host PC). I have written a simple loopback test in u-boot and followed the DP83867 Troubleshooting Guide (snla246a.pdf) to manually put the PHY into digital loopback mode and the loopback test can be run successfully using random payload data. I have also manually put the PHY into far-end loopback mode and sent ping requests from the host PC and captured (wireshark) both the sent ping and loopback response from the PHY (data matches for both ping and response). My question is what else could be preventing the PHY from sending data to the network?
The FPGA pins seem to add a small pullup load on the PHY signals which causes the PHY MII addr to be 0x0a even without any strapping resistors applied (signals are 0.83V at reset). The RX_CTRL line is strapped to be mode3 but with the FPGA pullup loading the voltage is 0.94V at reset (top end of the mode3 voltage range). (The u-boot and linux net drivers do have the "rxctrl_strap_quick" dts setting enabled.) All the rest of the strap configuration pins are 0V at reset. The PHY is powered with the following supplies: 3V3 (VCCIO), 2v5, 1v0 (really 1v1); not using 1v8. The 25MHz clk looks clean. I have also verified that the host PC can communicate with other embedded boards (different vendor then the target HW) over ethernet.
The DP83867 net drivers talk about a port mirroring configuration pin issue where if put into a N/A mode then the PHY can be placed into an internal test mode (disabling RGMII transmission). I don't see this specific case as a problem but are there other conditions that can place the device into internal test mode (preventing TX)? Is there some group of MII registers I can check to verify the PHY is in normal operation mode? Does the PHY ACT LED indicate data is without error or just the RX/TX_CTRL line is being toggled? Are there any timing specific issues when writing PHY MII registers that need to be accounted for (the net drivers don't seem to have any added delays between writing MII registers). Any other items to check would be greatly appreciated. Thanks.
-
Ask a related question
What is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
