DP83869HM: PHY not interfacing with FPGA based MAC

Prodigy 60 points

Replies: 10

Views: 79

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.

Thanks

10 Replies

  • 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 

  • 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?

  • In reply to Raymond Turner:

    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 

  • In reply to Justin Lazaruk:

    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.

  • In reply to Raymond Turner:

    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 

  • In reply to Justin Lazaruk:

    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

  • In reply to Raymond Turner:

    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 

  • In reply to Justin Lazaruk:

    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

  • In reply to Raymond Turner:

    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