2024-11-14 01:31 AM
Hello,
I'm using the STM32F767ZITx MCU and the lwIP library to transmit and receive UDP packets every 1 ms.
Everything works fine but sometimes, after the ARP table has expired, UDP packets are no longer transmitted for several seconds even though my STM has received a response to its ARP request (as seen with Wireshark).
What solutions are there to avoid this scenario? Is this normal lwIP behavior?
Thanks for your help.
2024-11-14 01:40 AM
Have you enabled LwIP diagnostics, and/or added your own diagnostics, to see what's going on - in particular, what changes when this problem occurs?
2024-11-14 02:38 AM
With my current system, I don't have a UART link available, I'm not on a proto board but a custom one.
What I'm seeing is that when I stop sending frames, the ARP table is empty, even though I'm receiving replies to ARP requests. It's as if it doesn't process replies.
2024-11-14 03:08 AM
@Armageddon wrote:With my current system, I don't have a UART link available
That's a major oversight!
Can you use SWO instead?
Can you reproduce the problem on a board which does have suitable access?
2024-11-14 03:30 AM
You don't have all the ins and outs to tell me it's an oversight.
We have our constraints, and that's the way it's done. It would have been simpler to have it, but I'll do it with the classic probe debugging.
If I really can't do it, I'll consider moving my program to a proto to find a solution more easily.
I may have an idea, given that the system keeps receiving frames every 5ms, maybe the input buffers are saturated.
Thanks for your feedback, I'll keep you posted.
2024-11-14 06:14 AM
Hello @Armageddon
you could visualize throw the SWD if you have STlink available throw the SWV(serial wire viewer) console print if you can use UART to redirect the print logs of LWIP this is documented in the following article Using the ITM console for printf redirects and LWI... - STMicroelectronics Community now regarding this statement:
"given that the system keeps receiving frames every 5ms, maybe the input buffers are saturated."
if it were to be saturated by receiving frames every 5ms why it didn't saturate before the ARP event happened, I don't think this is the case.
Regards
2024-11-14 06:31 AM
Thanks for your feedback, I'll follow your link to learn more and use it.
I'm about to do the test on a NUCLEO board after all, as I think I'm starting to point the problem and I'd like to see if I get the same behavior on the latter.
If I've understood correctly, the “MX_LWIP_Process” function ends up calling “HAL_ETH_ReadData”, which returns whether packets are ready to be read or not.
However, during the time when I'm no longer sending UDP frames because the ARP table is empty, this HAL_ETH_ReadData function returns “HAL_ERROR”, whereas with Wireshark, I'm seeing responses to ARP requests (I'm using a switch with a mirrored port).
I don't know why, but I'll try the test on a NUCLEO before going any further.