EMAC can't receive packet while transmitting

I performed more tests and I have additional information about the issue, if someone could provide any advice.

I tried polling the DMA status instead of relying on isr callback but no luck: so it's not a matter of irq; the DMA is indeed not triggered.
On the other hand the packet seems to be actually received at MAC level: if I inspect the RX_PCNT_GB register I see it increments whenever a packet is supposed to be received and it remains aligned to the TX_PCNT_GB register.
My only concern is that it increments by 20: I'd expect increments by 1.

The mac RX_ALGNERR_PCNT register increments as well and it matches RX_PCNT_GB, so there's definitely something wrong with the receive process a mac level. While the RX_ERR_CNT (0x14) register of ADIN1200 phy is always 0

I confirm that the issue happens only if I connect the ethercat slave which behaves like a sort of external loopback.
Whenever I send the same packet from an external device (I mean if it 's not the board own transmitted packet), it always receives it successfully via dma descriptor chain.

I checked again the 100/10 full duplex setting both in MAC and PHY and it's ok.

Hi,

Could you please confirm whether the loopback example you mentioned is the one included in the ADSP-SC598 BSP package?

Please refer to the attached example for transferring data between EMAC0 and EMAC1 on the SC598-SOM + EZ-Kit carrier board.

Test2_EMAC0_1_TX_RX.zip

Regards,
Nandini C

Hi NandiniC
Thank you for answering

I confirm the loopback example I mentioned is the one included in the SC598 BSP package.
The code you attached doesn't exactly apply to my EZ-kit because it assumes DP83848 and DP83867 PHYs, while I have ADIN1200 and ADIN1300 PHYs on the carrier board. I guess this applies to a different revision; I have rev.D.
Anyway the other relevant parts of the initialization, MAC and test setup match my code.

Please note that in my test I'm trying to tx and rx on the SAME port, which is MAC1+ ADIN1200 PHY.
If I use one mac for tx and the other one for rx it works perfectly. Same if mac1 tx and an external device sends back the same packet later. The issue happens only in the ethercat-like situation: one packet is received while tx is still ongoing.

In the meantime I discovered that if I setup the loopback mode (with adi_emac_phy_LoopbackEnable) I correctly get the packet back and the RX_ERR_CNT mac registers is always zero. There's still something strange, because besides the expected packet I also receive one or more 4-bytes long packets with apparently random data.

Disregard the fact I previously remarked that RX_PCNT_GB incremented by 20 instead of 1 as expected. This was actually due to my test code which performed tx retries when it didn't get the answer back.

Hi,

With all the observation you have provided, we would like to confirm that the EMAC on the SC598-SOM + EV-SOMCRR Kit is working correctly for standard Ethernet communication. The basic TX/RX functionality, similar to the loopback and normal Ethernet examples with external interface, operates as expected.

The issue you are facing appears only in the EtherCAT use case, where the returned frames are almost identical to the transmitted frames. Could you please confirm if our understanding is right, so that we can assist you better.

Regards,
Nandini C

Hi NandiniC

I eventually found that I had some padding bytes at the end of the Ethercat frame.
As soon as I removed the padding bytes the problem disappeared, so I proceeded in porting my EtherCAT controller into the kit and it worked.
I also discovered that this issue happens with some EtherCAT devices and not with others: is seems they send back the answer in a different way if the received packet has not the expected size and this doesn't agree with the ez-kit mac-phy, although with my old EtherCAT controller padding was ok.
I confirm this happens only in the EtherCAT use case (I mean communicating with a proper EtherCAT device) and not simulating exactly the same transactions with a generic ethernet device.

Unfortunately I later discovered that the same problems appears again when I use different EtherCAT devices or if I change the network device order or topology. It seems that in some cases the EtherCAT network introduces on the returning packets some sort of desync or delay which ther mac (or phy) of the ez-kit can't manage.

The other minor anomaly that I'm facing is that I receive duplicate DMA descriptors for every received packet and this happens in all use cases, EtherCAT or simply receiving generic Ethernet frames.
This seems to happen only if a single packet is received on the port: I poll the DMA descriptors and I find two of them valid, with exactly the same data. While whenever two or more packets are received, this results in the correct number of valid descriptors.
I implemented a simple workaround by filtering in my application code the duplicated packets, so this is actually not a great problem.
I don't exclude this is due to something else I'm missing or I'm doing wrong, like in the case of the packet padding.

I'm still testing to find a workaround to all this. Any ideas are welcome.