Part Number: DP83869HM
I have 2 DP83869 PHYs in between an FPGA which holds a gigabit ethernet IP core. I have 1 PHY hardware strapped RGMII to copper and the other is strapped RGMII to 1000Base-X. I have confirmed that the strapping is correct on each PHY, and I have a UART module which prints out the MAC and PHY register values, which also confirms that the PHYs strapping is valid. Inside the FPGA, I have an FSM which configures mostly the MAC registers, but I also write to register 0x18 (LEDS_CFG1) to get the ethernet jack LEDs working, which they seem to be. I have a solid link light and a blinking activity light when an ethernet cable is attached.
My issue is that I get no evidence of RGMII data passing between the MAC and PHY. I also get no valid speed, duplex or link up when reading register 0x11, even when my host PC sees the link as a valid gigabit link. I have verified all power lines, resetn is high and the 25Mhz clock.
How would I go about debugging this, and how would I determine where the issue with my system is? I am aware that this may be an issue with the MAC, but I am trying to explore all possible issues with this.
I would begin by using loopback tests to determine where the issue lies in the datapath. You can set the PHY in reverse loopback to verify that you have link and success data transfer between the PHY and the link partner. Then you can use Digital or Analog loopback modes to verify the MAC interface. These are configured through register 0x0016.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Justin Lazaruk:
Thanks for the input.
I did run an experiment where in the FPGA, I mapped the RGMII rx signals back to the RGMII tx signals for the same PHY and ran a signal analysis tool and the RGMII signals matched. This was basically a cheating loop back test.
Then I tried the BIST register, writing 0xF0A0 for the loopback test, but I couldn't really see anything. Running my program and plugging in an ethernet cable to the board with the other end connected to a switch that my computer was also plugged into deleted my computer's ethernet interface, to the point where I had to restart my computer and reinstall wireshark in order to view the ethernet interface again. Trying again, this time with the board plugged directly into my computer, and I didn't see any indication of a loopback, but wireshark would only display traffic when the board was connected and programmed.
My computer will show that there is a valid gigabit link when running the command wmic NIC where "NetEnabled='true'" get "Name","Speed" on Windows
In reply to Raymond Turner:
I did have another question regarding register 0x11, where the link status, speed and duplex are reported. I do not see an the same information that is on my host computer when I connect to the device. I read, from this register, 10Mbps, half duplex and no link detected. I turned off all advertising modes other than 1000Base-t half and full duplex, so I should not be seeing a 10Mbps link. Any advice on how to continue here?
Can you please provide the register information for register 0x0000-0x001F, 0x006E, 0x01DF when the device is in the faulty state? You mention you are testing multiple PHYs, which PHY is showing the link errors? A block diagram of the setup you are using to test would also be helpful.
0x00 11 40
0x01 79 49
0x02 20 00
0x03 A0 F1
0x04 00 01
0x05 00 00
0x06 00 64
0x07 20 01
0x08 00 00
0x09 03 00
0x0A 00 00
0x0D 00 00
0x0E 00 00
0x0F F0 00
0x10 50 48
0x11 03 00
0x12 00 00
0x13 00 42
0x14 29 C7
0x15 00 00
0x16 00 00
0x17 00 40
0x18 00 10 (Manually written)
0x1B 00 00
0x1E 00 12
0x1F 00 00
Unfortunately, we are not able to read registers above 1F in our current configuration. Are registers 6E and 1DF critical to getting this working?
This PHY is the one that is strapped for RGMII to copper where I have an ethernet port connected to it. After clearing the first PHY/MAC interfacing issues, I would imagine the second would be a similar fix.
Registers 0x6E and 0x1DF are extended registers in the DP83869. These can be accessed by following the instructions in section 184.108.40.206 of the DP83869 datasheet. These are important registers in determining the mode of the PHY and the state the device is set through bootstraps.
The register data provided shows that link is not up in the PHY, is this when your PC is showing link? I also see that no auto-negotiation abilities are advertised by the link partner in register 0x0005 and 0x000A, this could be why PHY is not able to establish link.
Can you confirm that there are no internal pull-up/pull-down pins on the FPGA interfacing the DP83869? An FPGA pull resistor connected to the DP83869 pin could affect the strap state of the DP83869, causing it to enter a mode you are not expecting.
Ok, I got the extended reads going, I tried the example given in that section and read back xC0F from register x170
0x6E 00 00
0x1DF 00 40
I should also mention that I disabled 10/100 auto negotiation by writing 0x0001 to reg 0x04 because I am only interested in 1000Base T/X on this PHY. These register reads are for the PHY in RGMII to copper only, as that is the one I am working on for now.
I do not think so. I looked through the device's data sheet and did not really see anything regarding internal pull resistors. I will continue to look into this, however
Can you try enabling Mirror Mode through strap or register settings (0x0031 = 1)? The DP83869 is not recognizing the auto-neg abilities of the link partner, I'd like to see if the FLPs are being sent over the opposite channels.
You are correct, the DP83869 does not recognize the link that your PC seems to indicate. Can you try different link partners to determine if they are able to link to the DP83869?
I followed the same steps as reading extended registers, except with address x32 this time and added a write to register 0xE of x0001 and confirmed by reading a x0001 from register 0xE from my UART. This caused my computer to not see a valid link when running the command mentioned previously. Getting rid of this extended register write did bring back my computer's link to the device.
I have tried one other windows computer and I get the same results. I will be able to try it with a Linux machine soon as well but I don't expect anything different
Can you confirm that you tried register 0x0031=0x0001 (not address 0x0032)?
Can you please share a schematic of the application?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.