• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 1189 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DP83867CR: DHCP not working with Xilinx FPGA

Tifei Hsu
Prodigy 50 points
Part Number: DP83867CR
Other Parts Discussed in Thread: DP83867IR

Hello,

Hardware: Xilinx Zynq XCZU7CG + TI DP83867CRRGZ

When I built the u-boot and linux kernel, with petalinux default settings, I only get the static IP mode working: ping and tftp ok. Macb driver is fine after I modify the system-user.dtsi but still DHCP not function.

Static IP mode works telling me that the hardware, board level connectivity are good.

So I use WireShark to check what exactly the zynq MPSOC pops out. I found that the packets are padding all 0s or chopped shorter. Never a good DHCP Discover packet is sent. See the attached picture.

I found that Xilinx Evaluation board ZCU!06 use the same TI DP83867IR but with different package. However they are both use as RGMII mode. That's good.

So I built the u-boot and kernel on it. The DHCP works perfectly.

Well, I think U-boot or kernel does not know TI PHY are in different package.

Q1: Is it possible the PHY chip could cut the packet or change the content of the packet?

I put a scope om MDIO. When I enter "DHCP" command, I see some activities on it.

I am thinking the driver tells TI PHY to do something when DHCP is issued.

Q2: Could it be possible when the MAC "notifies" PHY, the signal is bad to cause the DHCP packet end early?

Also attach my schematics.

Please advice, thank you.

  • 0
    TI__Genius 11900 points

    Hello,

    Since you are able to transfer data, I assume that the PHYs are linked up. Can you please confirm this?

    The zero-padding and corrupt packets suggest that this could be a timing issue. Please configure the RGMII clock skew and see if it helps.

    Thanks,

    Vibhu

  • 0 in reply to Vibhu Vanjari
    Prodigy 50 points

    Hi Vibhu,

    Thanks for the reply.

    1. Yes the PHY is linked up. By reading boot log and also mii status registers both are showing link is up and ready.

    2. When you say "configure RGMII clock skew", do you mean that we try different mode like datasheet page 48?

    Please advice, thank you.

    Tifei

  • 0 in reply to Vibhu Vanjari
    Prodigy 50 points

    Hi Vibhu,

    If the RGMII clock skew is bad, how come I can still transfer data?

    Is this a "packet length/type sensitive" case? Is DHCP packet so different from the packets of ping and tftp packet?

    Please advice, thank you.

    Tifei

  • 0 in reply to Vibhu Vanjari
    Prodigy 50 points

    Hi Vibhu

    After collect all co-workers' effort, here are the narrow down comments:

    Static IP mode working detail:

    PC <-> PCB. Ping each other is good. The WireShark captured the ping packets is less than 100 bytes, about 74 bytes.

    PC -> PCB download 32MB file by tftp OK. So RX is good.

    PC <- PCB upload 1KB file by tftp failed.

    PC <- PCB upload few bytes data by tftp OK.

    => So there is something wrong about transmitting long packets.

    DHCP mode:

    Under U-boot, send "DHCP" command, PCB should send out DHCP packets. However DHCP packet is 347 bytes long, it is chopped to less than 150 byte packets.

    => So the DHCP is not working is because at TX side there is "zero-padding" and "corrupt packets" issue.

    It looks like a TX timing issue. 

    We scanned all 16 TX clock delay values in PHY RGMII Delay Control Register (0x0086) but no luck, long packets are still cut to short packets.

    Any other suggestion please?

    Could it be the RJ45 connector we use? 

    Attached its datasheet and also the timing waveform we captured.

    Please advice, thank you.

    loopback.xlsxGD1-WN-0003(19030-00)-A.PDF

  • 0 in reply to Tifei Hsu
    Prodigy 50 points

    Solve the problem !

    The PS side reference clock should be 33.3333MHz, ours is 33MHz. After replace to 33.3333MHz OSC, DHCP is working. Ethernet is working.

    Learned experience:

    If a feature is partially function or running shaky, check the OSC frequency. When order parts, MUST tell vendor the exact value. For example, 33 MHz must say 33.000MHz, 33.3333MHz must say 33.3333MHzm not 33.3MHz.

    I guess latest technology is more sensitive to the frequency than the old ones.....