TMDS64EVM: PRU Tx Ethernet is Intermittent

Seth Appleman said:

I have the following code that I run to transmit Etherner data out my configured MII_RT ports to my host PC. I only see data show up at the host PC (via wireshark) some of the time.

I would suggest using an external network TAP to rule out host-side drops, as the NIC on your PC may be silently dropping packets - particularly short ones. Without visibility at the wire level, it's difficult to call the behavior truly "intermittent." and difficult for us to comment.

Anyways, a few things worth checking:

1. IPG (Interpacket Gap): Verify that PRU_ICSSG1_PR1_MII_RT_PR1_MII_RT_CFG is set to 0x0B wire clock cycles (96ns at 1Gbps). If a packet is pushed before the IPG expires, the gate will hold it until the gap clears, so this alone shouldn't cause drops - but it's worth confirming.

2. Back-to-back transfers: If you are sending consecutive frames, wait for the TX L2 FIFO to fully drain before writing the next frame. Overwriting FIFO contents before the previous frame has been transmitted will corrupt it. Your firmware should take care of this, but it's worth verifying.

For point:2, FIFO fill level: You can read the FIFO fill level to confirm the previous frame has fully drained before pushing the next one.

xin     TXL2_XID, &R19, 4
and     R19.b2, R19.b2, 0x7F   
qbge    exit?, R19.b2, 0            ; don't push new packet

Btw, EOF and CRC flags you've configured in R31, looks correct.

BR
JC

IPG is currently set to 0x18 right now based on a TI demo project I had been referencing. I am configued for 100 Mbs. I also added that "delay" to check the bytes in the FIFO before issuing a new transmit. With consistent packet sizes, there is still  an inconsistency in which packets are transmitted and which are not. I do not have access to a external network TAP (at least not immediately).

I notice that when I step through the code manually, all my packets are transmitted. When I just run, there are issues. This suggests something timing related. Other that IPG (should I increase it?) and waiting for R19 status register TXL2Occ to be 0, what other timing related issues are needed to be investigated?

Seth Appleman said:

I notice that when I step through the code manually, all my packets are transmitted. When I just run, there are issues. This suggests something timing related. Other that IPG (should I increase it?) and waiting for R19 status register TXL2Occ to be 0, what other timing related issues are needed to be investigated?

Can you share me the ICSSG dump? I'm more interested on these error counters?

BR
JC

FYI, Required IPG is 960ns/40ns = 24 clock cycles. To get 24 cycles, you program 24 - 1 = 23 = 0x17 because the counter counts 23->0 (taking 24 cycles), then transmission starts on the next cycle after expiry

BR
JC

Can you explain where that detail came from? I maxed out the IPG and that didn't work, but am not sure about where the numbers in your calculation are coming from. When you say "required", what is that based on?

Here is the reference.

BR
JC

Sorry let me clarify my question... where did you come up with "Required IPG is 960ns/40ns = 24 clock cycles"?

Seth Appleman said:

Sorry let me clarify my question... where did you come up with "Required IPG is 960ns/40ns = 24 clock cycles"?

1G mode, the TX interface clock runs at 125 MHz. This is the standard clock rate required to transmit gigabitdata i.e 125Mhz = 8ns

100M mode, the TX interface clock runs at 25 MHz. At 100 Mbps, the interface clocks at one-fifth the speed of 1G i.e 25 MHz = 40ns

the 125 MHz or 25 MHz clock coming from the PHY interface

as per 802.3 standard 96ns is the min IPG for 1G, 960ns for 100Mbit

Now for ICSSG configuration - as per TRM:

For 1G -> 96 ns ÷ 8 ns - 1 = 11 = 0x0B

For 100M -> 960 ns ÷ 40 ns - 1 = 23 = 0x17

0x17 or 0xB value is in-terms of TX interface CLK  

BR
JC