First UDP packet sent contains all zeroes in the payload, second packet has partially false values in the payload, all the other packets that come after have correct payload. Why does this happen with the first packets?

[Nick1234569]

Hello everyone,

I'm using the STM32H7 and the new fully reworked ethernet driver along with the LWIP and FreeRTOS for sending and receiving the UDP packets.

The issue is first two packets get corrupted when sending. I don't send the UDP packet with zeroes in the payload, but the first sent packet is filled with zeroes.

I've tried placing a delay in case the Ethernet is not properly initialized but that didn't fix anything.

I suspect that the memory gets corrupted, but cannot prove anything.

Does anybody know what could be the potential issue here?

Thanks

[Pavel A.]

Do you use static IP address or DHCP? Are you referring to DCHP requests or ARPs that the LwIP sends out?

[Nick1234569]

Hi Pavel,

I am using DHCP.

I'm not referring to the DHCP or ARP requests.

I'm sending (broadcasting) a custom payload using the sockets API.

So, the UDP packet with a custom payload (39 bytes in length) is broadcasted

(sent to 255.255.255.255).

[Andrew Neil]

"first two packets get corrupted when sending"

How do you know they're corrupted on sending - rather than in the receiving ... ?

[Nick1234569]

Hi Andrew,

Because I've seen that the data sent out by the Ethernet driver uses corrupt data for some reason.

Even though that memory location should have proper data.

I've checked for stack overflow but that is not the case.

When I create the packet buffer on the stack and then introduce a delay of 2 seconds

and then send, there are no faulty packets at the start.

1. Initialize the buffer with the payload
2. Delay 2 seconds
3. Send the buffer

Proper packets are sent out.

Without the delay, the two corrupt packets are sent.

Don't know why does the delay help.

[Andrew Neil]

Are you doing something like passing a pointer to a local (auto) variable - so that what you pointed to is no longer there by the time the driver actually comes to send it ... ?

[Nick1234569]

The buffer is static and it is only changed there, so that shouldn't be an issue.

[Bob S]

Caching issue? There's been a good discussion of this here (https://community.st.com/s/question/0D53W00001Z9K9TSAV/maintaining-cpu-data-cache-coherence-for-dma-buffers).

[Nick1234569]

Hi Bob,

I've tried changing the MPU settings but it didn't help.

I'll check the discussion.

[Nick1234569]

Hello everyone,

Just an FYI,

I added the clean data cache for the packet buffer which is sent over the UDP right before sending

and that appears to have fixed the issue (for now, at least).

Now, the initial packets and all the others that are sent out are fine.

I think the issue was that the data was updated and placed in the cache and the same buffer wasn't updated in the SRAM which is accessed by the DMA which takes the old values and sends them instead of the new updated ones which haven't been written through to the SRAM.

Thorough testing will follow.

SCB_CleanDCache_by_Addr((uint32_t*)(((uint32_t)packetBuffer) & ~(uint32_t)0x1F), packetSize+32);
sendPacket(packetBuffer, packetSize);