Other Parts Discussed in Thread: TMDX654IDKEVM,
Hello,
I'm working with a commercial real-time operating system on the TMDX654IDKEVM with AM6548 SR 2.0. The OS includes a device driver for PRU ICSSG Ethernet which supports six interfaces on ICSSG #0, 1 and 2. Testing this driver has uncovered the following problem:
When two interfaces on the same ICSSG are connected directly together via a single RJ-45 cable (for example: ICSSG #0 interface 0 <-> ICSSG #0 interface 1), the receive path of one of the PRU interfaces may fail to work correctly. The symptoms of the failure are that no frames are received after the PRU ICSSG interface is brought up. This condition persists until the board is reset (via the DMSC) or power-cycled.
I have been able to reproduce this failure on ICSSG #0 and 1 but so far not on ICSSG #2.
The failure does not occur if the two interfaces are connected via a switch, nor does it occur if interfaces are "cross-connected" to different ICSSGs (for example: ICSSG #0 interface 0 <-> ICSSG #1 interface 1).
The failure does not occur if the PRU ICSSG Ethernet interfaces are started with the link disconnected and the link is then connected.
Looking in the MSMC SRAM when the receiver has stalled, the entire MSMC SRAM is filled with zeros except for 32 bytes in the Rx context area which are the first 32 bytes of the first in-bound frame (a gratuitous ARP request, 60 bytes plus FCS). There is no sign of the remainder of the frame. This suggests to me that the physical layer is working correctly but the PRU is for some reason unable to receive the whole frame.
I have been able to reproduce this consistently with several versions of the PRU EMAC firmware including 02.02.09.0[2367].
Any suggestions as to what might be going wrong here, or how to diagnose/correct the root cause of the problem?
Thanks in anticipation.
Ian