AM3359: PRU Dual EMAC same packet repeated several times randomly

Hello Andrea,

Apologies for delayed response. I am checking with the development team to see if they have any input.

Could you tell us a bit more about your testing methodology?

Regards,

Nick

Hi Nick,

   actually I have tested the same behavior even with normal ping.
I have ICEv2 with device tree am335x-icev2-prueth.dts connected to my laptop PC.

I configure eth0 to 192.168.1.2 and I ping my laptop PC 192.168.1.1 with a fixed size packet of 286 bytes.

On the oscilloscope I have a trigger on the rising edge of TXEN on the phy TLK110.

I see few repetitions of the same packet.

What I have discovered, also, is that the last repetition is a little longer: so I suppose the PRU firmware stops transmit for some unknown reason and just sometimes it reaches the end of the packet.

I would appreciate if you could copy/paste the link to PRU firmware source code to inspect.

Looking forward.

   Andrea

Hi Nick,

   any update ?

Looking forward

   Andrea

Hello Andrea,

1) Why did you start running these tests? Was it because of the transport latency, or something else? Please provide details on the latency you expect, and the latency you observe.

2) I am not super familiar with how TXEN relates to packets. When you do an Ethernet packet capture (e.g., with wireshark), do you actually see repeated packets getting sent?

3) What does your devicetree node look like for PRU Ethernet? It looks like TX IRQ was removed by default going from Linux SDK 6.3 --> Linux SDK 7.3: https://software-dl.ti.com/processor-sdk-linux/esd/docs/07_03_00_005/devices/AM335X/linux/Release_Specific_Migration_Guide.html . One thing you can try is to add the devicetree entry for the TX interrupt back to the devicetree node.

Regards,

Nick

Hi Nick,

   we would like to measure PRU firmware transmission latency because is part of the total latency time of our application: our target is that between a trigger, detected by the application software and a packet notification delivery will last 1 ms max.

I confirm that devicetree doesn't include TX IRQ: anyway I have also tried to add it but result is unchanged.

<< What we have discovered is that the last repetition is a little longer: so we suppose the PRU firmware stops transmit for some unknown reason and just sometimes it reaches the end of the packet. >>

I would appreciate if you could copy/paste the link to PRU firmware source code to inspect. Previous SDK (an so previous PRU FW) is not affected by this problem.

Looking forward

   Andrea

Hello Andrea,

The AM335x PRU dual EMAC source code for SDK 6.3 is in the RTOS SDK 6.3, as detailed here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/962754/am3356-pru-icss-dual-emac-source-code-prueth-fw-availibility . I am not sure if the firmware source code is posted anywhere for Linux SDK 7.3. Please note that TI does NOT support modifications to the firmware. You are welcome to make edits, but we cannot help you debug, and we cannot answer questions about modified code.

I am reassigning your thread to another team member to comment on
1) source code for the SDK 7.3 PRU Ethernet
2) TXEN function if they know anything about that signal

In the meantime, please do an Ethernet packet capture to verify what signals are actually coming out of the PHY.

Regards,

Nick

Thanks Nick for your help.

Sure, I did an Ethernet capture with wireshark and I don't see repeated packets coming out from PHY but ... it is probably because on the wire there are invalid frames (an oscilloscope with ethernet protocol decoder should be used to inspect this problem).

TXEN is the pin used by the MAC interface to let the PHY fetching data from TXD0 ... TXD3.

Looking forward

    Andrea

Hi Andrea,

Sorry for the delayed response.

We are trying to reproduce the issue at our end to debug further. Debug got delayed due to setup related issues at our side.

I will get back to you with additional information at the earliest.

Meantime can you please check weather this issue is port specific? Means this behavior is observed in only Port1 or Port2 or Both ports? 

Regards,
Mohan.

Really thank you Mohan for having taken in charge this issue.
I will check within tomorrow if the issue is affecting only a specific port.
Looking forward

    Andrea