DP83869HM: PHY not interfacing with FPGA based MAC

Hi Raymond, 

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. 

Regards,
Justin 

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

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?

Hi Raymond,

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. 

Regards,
Justin 

Sure,

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.

Hi Raymond, 

Registers 0x6E and 0x1DF are extended registers in the DP83869. These can be accessed by following the instructions in section 9.4.9.1 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. 

Regards,
Justin 

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

Hi Raymond,

Can you try enabling Mirror Mode through strap or register settings (0x0031[0] = 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? 

Regards,
Justin 

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

Hi Raymond, 

Can you confirm that you tried register 0x0031=0x0001 (not address 0x0032)?

Can you please share a schematic of the application?

Regards,
Justin