cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 Ethernet TX corruption

PEmme
Associate

So I fought through the growing pains of getting ethernet working on the H7 for a streaming project. So far I've had good luck on the RX side but I'm getting some strange corruption when doing TX load testing.

Under a pretty high load I get a corrupted TX packet every 4000-5000 or so. These packets have bursts of corruption usually around 700 bytes in with the length varying from 8 bytes to maybe 64 bytes. Which is the odd thing, the corruption always starts on a 8 byte boundary and is a multiple of 8 bytes long.

I wondered, and tried to check, to see if I was corrupting the packet on send, cache was in the way, or some issue with DMA. I haven't found anything and the other odd thing is that I've run this with store-and-forward + crc gen setup on the TX fifo. So even if the data was getting corrupted via DMA, for example, the CRC should be "correct" but it's not. It's as if the data makes it into the fifo correctly, crc is generated from this, but then as the data gets clocked out of the fifo it gets a corruption every so often.

I haven't found anything in the forms like this, nor is there anything in the errata. Does anyone have any ideas or have heard about something like this?

Thanks -phil

3 REPLIES 3
Piranha
Chief II

Is it really Ethernet CRC, that's failing, or maybe TCP/UDP checksums?

Defective cable(s)?

PEmme
Associate

Good point for clarification/correction. I always see the UDP checksum mismatch, because there's a burst of corrupt data in the packet. Although at times I've seen the CRC counts rise in the switch, but that's more rare. This issue does move around a little.

I've tried different cables and network setups, but no real change. The fact that the FCS is usually correct and that the corruption is perfectly aligned to 8 bytes tells me it's inside the H7 somewhere, but I have no idea where.

Bilge
Associate III

Did you come to any conclusions regarding this problem?