cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
1,649 Views
Registered: ‎12-28-2016

EMACPS receiver problems with TI DP83867

Jump to solution

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

 

0 Kudos
Reply
1 Solution

Accepted Solutions
Observer
Observer
1,447 Views
Registered: ‎12-28-2016

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

rd0.jpg

RXC

image002.jpg

 

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

 

 

View solution in original post

0 Kudos
Reply
4 Replies
Observer
Observer
1,618 Views
Registered: ‎12-28-2016

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

2018-06-28 09_03_04-MmcCells.sdk - Debug - Disassembly - Xilinx SDK.png

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

2018-06-28 09_03_50-MmcCells.sdk - Debug - Disassembly - Xilinx SDK.png

0 Kudos
Reply
Observer
Observer
1,563 Views
Registered: ‎12-28-2016

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):
image.png
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).
image.png
 
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:
image.png
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
0 Kudos
Reply
Moderator
Moderator
1,516 Views
Registered: ‎08-25-2009

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.

"Don't forget to reply, kudo and accept as solution."
0 Kudos
Reply
Observer
Observer
1,448 Views
Registered: ‎12-28-2016

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

rd0.jpg

RXC

image002.jpg

 

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

 

 

View solution in original post

0 Kudos
Reply