EMACPS receiver problems with TI DP83867

[tpcorrea]

Dear colleagues,

I am working in a project with a self-developed board that uses TI DP83867 PHY for ethernet comm. The SoC is a buy-in module from KnowRes that has a  Zynq 7030 (xc7z030ffg676-1) device. The PHY is connected via MIO to EMAC0 and I run the Echo_Server application with lwip 1.8.

Though I can establish connection with the link partner and auto-negotiation has the correct result, my EMAC does not receive ANY packet.

Here is what I tried/measured/know:

- The RX signals out of the PHY (rxc, rd, rx_ctl) seem to be fine.

- I am able to transmit a packet to the link partner (the host PC receives the gratuitous ARP).

- All the phy registers seems ok.

- sclr_mio_pin_22 to 27 are configured as 0x1303.

- the EMAC statistics for the receiver stay in 0.

- I changed the rx clock delay from 0 to F (0ns to 4ns) and it had no effect.

- Two (long) days ago, it worked fine for a while.

Does anyone have a clue of what could be? 

Thanks in advance,

Tomas

[tpcorrea]

Here are the GEM0 statiscs registers. 0xEB000B158 is number of received packets.

And here the GEM0_RX_CLK enabled and the TX clock is correctly configured to 125MHz (1000Mbps):

[tpcorrea]

Hi, everyone. This is a follow up post.

Well, as the board I developed has many Ethernet ports (11 in total), I modified the design to use one port that is connected to the PL. I used the RGMII to GMII and connected it to the GEM (hard MAC). As now the signals are in the PL, I can use the debugger to see what is going on.

Well, at the first try, I could not receive the packets and got the following signals (rx only):

And if we zoom the beginning, we can see that the data is misaligned, i.e., the octets are not being re-constructed correctly (rxd[3:0] is one clock later than it should).

When I increase the rxc delay, then the data alignment was corrected, though I still get the first rx_er at the beginning of the frame:

I still have to review the RGMII specs and measure the signals to figure out what exactly is going on and how to proper set (each) PHY.

Tomas

[nanz]

Hi @tpcorrea,

The Zynq GEMs do not add clock skew to the TX/ RX clock, therefore the skew must be added by the PHY or the PCB trace.

[tpcorrea · Accepted solution]

Hi, colleagues,

I found at the end the reason for my problems and leave it here hoping it can be useful to someone. Well, the Texas PHY has a weak driver for the Rx signals, i.e., Rd(3:0), rx_ctl and rxc, specially with 1.8V VDDIO.The PCB + the Zynq input capacitance represents a heavy load and the rise and fall times are ~4µs, so the signals look like this:

RD0

RXC

As a solution, I will increase the supply voltage to 2.5V, because the drivers become stronger and hopefully it my solve my issue. If not, re-driving the PHY signals will be necessary.

Also, as a lesson learned, be advised that the MAC does not process a packet if the error signal from the PHY is asserted. It's obvious now, but it was hard for me to learn it.

Cheers,

Tomas