ENET on S32R274: broken transmitted frame

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

ENET on S32R274: broken transmitted frame

1,026 Views
isolenta
Contributor II

I'm trying to transmit ethernet (actually ICMP echo responses) frames using ENET on S32R274 (on EVB evaluation board). Receiving of frames looks like a correct.

ENET configured to accelerate checksum calculations both for IP and protocol headers. I put tx descriptors and tx buffer to the separate section and configured SMPU with Cache Inhibit bit for this segment. Also I configured CMPU with cache inhibition for there addresses.

Frames transmitted successfully, but in Wireshark I see that there are a few "broken" octets in the transmitted frame and as result wrong protocol checksum. I particular, few bytes in the frame that should be in position OFF are found on position OFF+10, and there are garbage in the position OFF. It looks very like cache issue, but I used CMPU and SMPU settings for these regions.

How I can to make sure if MPU settins are applied actually?

Probably it's not caching issue but miscofiguration or misunderstanding of how other thing works? For example, wrong clocking or issues with PHY chip (ksz9031rnx)? How I can debug and isolate possible bug?

0 Kudos
1 Reply

1,010 Views
isolenta
Contributor II

During figuring out I enabled internal loopback on ENET (RCR.LOOP = 1), switched off transmit accelerate features (CRC generation). Issue still here, so PHY is out of suspect now.

 

I dumped transmitted frame (dump just before TDAR=1) and dumped received frame on loopback side (dump in rx interrupt):

transmitted:
40016280: 3E CD 36 66 5B 64 11 22 33 44 55 66 08 00 45 00 |>.6f[d."3DUf..E.|
40016290: 00 5C 00 00 00 00 40 01 00 00 C0 A8 02 0A C0 A8 |.\....@.........|
400162A0: 02 01 08 00 00 00 00 00 00 00 00 01 02 03 04 05 |................|
400162B0: 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 |................|
400162C0: 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 |.......... !"#$%|
400162D0: 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 |&'()*+,-./012345|
400162E0: 36 37 38 39 3A 3B 3C 3D 3E 3F                   |6789:;<=>? |

received:

4000EA82: 3E CD 36 66 5B 64 11 22 33 44 55 66 08 00 45 00 |>.6f[d."3DUf..E.|
4000EA92: 00 5C 00 00 00 00 40 01 00 00 C0 A8 02 0A C0 A8 |.\....@.........|
4000EAA2: 02 01 08 00 00 00 00 00 C0 00 00 01 02 03 04 05 |................|
4000EAB2: 06 07 00 00 0A 0B 0C 0D 0E 0F 10 07 08 09 0A 15 |................|
4000EAC2: 16 17 18 19 1A 11 12 13 14 15 20 21 22 23 24 1B |.......... !"#$.|
4000EAD2: 1C 1D 1E 1F 20 2B 2C 2D 2E 25 26 27 28 29 32 33 |.... +,-.%&'()23|
4000EAE2: 34 3F 38 2F 30 31 32 33 34 3F                   |4?8/01234? |

Corruption starts at fourth row after '06 07' bytes and after '0F 10' and further.

 

0 Kudos