STM32F1 ETH UDP TX loosing packets

[MathiasZ]

In my project i have a ethernet communication in between a PC and a STM32F107 uC device. When everything works fine the PC sends a request to the uC-Device and this one sends a echo back to the PC when everything from the request is done. Because of time critical applicatoin i use UDP protocol and send messages with the low_level_output(..) function.

But sometimes if a broadcast from any network-device comes between the pc message and the echo then the pc never gets the echo. I already found out that the uC gets the pc request and tries to send a echo back.

I already tried following things:

-Check if the uC device gets the message --> Message is there

-Check if the uC device sends the message with low_level_output() --> Seems fine

-Enable ETH_DMA_TX error interrupts --> Nothing

-Changed mode from half duplex to full duplex --> Nothing changed

Would be fine if anyone have a tip for me...

Attached: Wireshark recording

[Piranha]

Are You using lwIP but calling low_level_output() directly from application code? If so, that's plain wrong and makes IP stack useless. The most lightweight API for application usage is "raw" API. Specifically for UDP:

https://www.nongnu.org/lwip/2_1_x/group__udp__raw.html

Also are You using RTOS? If so, You have to take into account thread synchronization. Read this:

https://www.nongnu.org/lwip/2_1_x/pitfalls.html

[Mathias Zviedris]

Hi Piranha,

i only use LWIP for HTTP, NTP and so on ...without RTOS. At the Moment i think i found the cause of the error (its more a workaround than the cause itself). Yesterday i disabled the RD: (Retry disable) bit in the MACCR register . Over the night i tested the communication and there was no error within 24 000 000 packets :-). It seems that there was something like a collision and the uC have not made a retry. But at this point i dont know, why the collision Interrupt is not called.

By the way the RD bit was set by CubeMx 4.25.0 and F1 1.6.1 package.

In the next steps i will make further tests. If nothing goes wrong then removing the RD bit of the MACCR register is the solution for this problem.

[MathiasZ]

So after testing i know that the problem is still alive. I tested the communication in half-Duplex (Retry Disable Bit = 0) and also full-duplex. In both modes i`m losing udp tx packages (sending in raw mode with low_level_ouput() ). Would be great if anybody can give a tip.

Summary:

-No RTOS

-Sending with low_level_output() (raw mode)

-Already tested half-Duplex in 10Mbit mode with RD-Bit = 0

-Already tested full-Duplex in 10Mbit mode

-Losing tx packages sometimes --> It seems that in the same time a broadcast is received...