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.

DP83822I: Problem with DP83822I

Part Number: DP83822I

Tool/software:

Greetings! I am using this part for a very first time! I have connected DP83822 to Xilinx Zynq. The problem is the communication between the Zynq and DP83822 is not OK. For example I can set registers through the DPIO, but when I try speed autonegotiation for example, I can set the corresponding flags, but the flag auto-negotioation completed never goes high. I on the Zynq side I always receive a message Phy setup error and Ethernet Link down. It is the same when I use preset speed. Can you check my schematic? Have I`ve done something wrong? The Zynq side is working on 1.8V and I have supplied the VDDIO with 1.8V in order to make the IO pins of the DP83822 workinDP83822 TI.pdfg on 1.8V..

Do you see anything wrong?

Thanks!

  • Hi Pavlin,

    Thanks for reaching out!

    One possible concern with schematic is J1101 RJ-45, does this have integrated magnetics? Please share the part number so I may review.

    Here are some clarifying questions to help me understand possible causes:

    • What link partner is being connected on the copper side? Does it have the same auto-negotiation mode / speeds enabled?
    • If registers are accessible, please share a register dump from addresses 0x0 - 0x1F while the link partner is connected.
    • What is the MAC interface Zynq is expecting from the PHY?

    Thank you,

    Evan

  • The RJ-45 has integrated magnetics. The part name is LPJ0025GENL. It is a cheap connector, but this is what i`ve got when I assembled the pcb. I don`t high  speeds here.

    Zynq corretly found that it is a TI PHY and it loaded its registers. You can check the both pictures. I read all of them just after the auto-negotiation is activated from the Zynq.

      

    One thing caught my eye. The datasheet of the DP83822 says it`s address should be 0x01, but the Zynq finds the chip on address 0x0F.  And 0x19 register has 0xa02f, which corresponds to 0x0f as address.  And the Pause RX Status bit is set.

    Best regards!

     

  • Hi Pavlin,

    Thanks for confirming and sharing register reads. I reviewed the datasheet for LPJ0025GENL, and do not see any concerns with MDI side of schematic.

    Regarding unexpected PHY address, it seems the FPGA is driving the strap pins on start-up and affecting the strapped PHY address (and possibly other PHY mode straps). To avoid this, please try powering the PHY first and allowing time for strap pins to sample before FPGA drives the lines.

    I see some other unexpected register values (0x16 = 0x2, loopback enabled) - is there an initialization script being used to write PHY registers on start-up?

    Best regards,

    Evan

  • Ok! I am learning, but little bit slowly. It seems I have made a mistake with the strap resistors. My interface is RGMII and I didn`t have a resistor group on the RX_ER pin. So I added 13k pull up and 2k pull down restors on this pin according to table 8.8 and table 8.10 in order to select RGMII. The device address changed to 23, but still the link is down. Do I have to enable something else? EEE_EN? AMDIX_EN?

    Thanks!

  • Hi Pavlin,

    Nice catch on the strap, 13k PU / 2k PD on RX_ER is correct to enable RGMII.

    The PHY configuration for link up on MDI-side looks good (auto-negotiation enabled with all advertisements).

    If you have doubts about the physical pin-mapping on the RJ-45 / cable to the link partner, enabling auto-MDIX via straps is recommended (RX_ER to mode 3).

    The other possibility for link failure is the link partner settings - can you please confirm what device is connected on the copper side, and if it has auto-negotiation enabled with 10/100M advertisements?

    Thank you,

    Evan

  • I am using auto-negotiation on the link partner, but as far as I see there are many different modes for the DP83822. Table 8-11 in the datasheet. I can use fixed speed rate on the link partner(Zynq), but I am not sure which one should I check if it is selected according to table 8-11. 

    Is there any example hardware configuration and corresponding used speed mode.

    Because now when I set the auto-negotiation procedure in DP83822, the corresponding flag for complite auto-negotiation never goes high. So I am thinking I haven`t selected the correct mode of operation.

    Any ideas about that?

  • Hi Pavlin,

    Is the Zynq acting as a transceiver? The topology is unclear to me, please share a system block diagram so I can further understand.

    Regarding Table 8-11, the recommended mode for auto-negotiation enable is AN_EN, AN_1, AN_0 = 1, FX_EN = 0.

    If auto-negotiation complete is not flagging high, the issue may be:

    • PHY or its link partner are not configured to enable auto-negotiation, or have incompatible speed advertisements
    • Issue with cable connection between PHYs
    • PHY is not powered, or has invalid input clock on XI

    Thank you,

    Evan

  • Here is the full schematic DP83822 full schematics.pdf

    Here are the changes I made -> I added R26 and R27(2K2 pull up) to RX_D0 and RX_D3. I also removed R17 in order to separate the LED_0 from GND and added R28(2K2 pull up). All this in order to ensure AN_EN, AN_1, AN_0 = 1.

    So I am positive that the 25MHz oscillator is working, and I have connection between the host(Laptop) and DP83822. 

    Can you confirm that my hardware is OK, so I can start playing with the registers of the chip?

    Thanks!

  • Hi Pavlin,

    These straps are correct to enable auto-negotiation advertisements for 10/100M, but please note they will also change the PHY address.

    Although the default values of these straps will enable the same advertisements, adding pull ups is not an issue. 

    PHY_AD[4] = '1'

    PHY_AD[0] = '1'

    I expect strapped PHY address to be 0x11.

    If you have register access, please share a register dump while connected to a link partner.

    Thank you,

    Evan