Sending a UDP frame freezes in an unrecoverable way
Posted: Sun May 17, 2026 2:44 pm
Hi,
I have a project which is a wireless remote control for driving a real boat. Its main processor is a STM32H7 and it is fitted with a ESP32-C3 running SPI-AT as a coprocessor to handle wifi communication, and it communicates with the boat system using repeated UDP frames back and forth.
The remote sends a 22 byte binary frame, to which the boat responds a 44 byte binary frame, and this is repeated about 3 times a second.
I notice freezes that completely stop the traffic in such a way that the only remedy I found is resetting the ESP32 and re-configuring it, but this takes way too long and is not acceptable in the context of driving a boat.
The problem occurs in the sending process. It works a follows (seen from the STM32H7):
{
Send command "AT+CIPSEND=%d\r\n"
Wait for handshake pin for max Timeout1 (200 ms)
Get the response
Check if response is "\r\nOK\r\n\r\n>"
Send the payload part (here, a 22 byte array)
Wait for handshake pin for max Timeout2 (600 ms)
Get the response
Check if response is "\r\nOK\r\n"
}
After a few hours of exchanging 3 messages per second, the system freezes. In one example, it froze after more than 27,000 exchanges. What happens is that the second waiting for handshake takes more than the timeout value. Initially this would put my system in an error state, but I noticed that then the UDP frame was sent anyway. I then decided to just ignore the timeout, so that the operation continues normally. This incident can occur several times (tens of times) without any problem. But eventually, something different happens.
This time, the frame is not sent when the timeout2 occurs. Since the event is ignored, there will be a next time attempting to send a UDP frame, but this time, the process fails at Timeout1. From that time on, not only the ESP32 cannot send frames, but the frames it receives are not detected nor read. So the traffic completely stops, and so far my only choice is to reboot the remote control.
I have measured statistics of the time taken for the handshake pin to be activated. Here is the result. The graph shows the values sorted by increasing values.
One can see that about half the values range from 230 to 300 ms, then about a third of the values are remarkably constant at about 370 ms, then a new step to a value of about 570 ms, and then a few values above, including infinity.
What could be the cause of this problem?
I have analysed the traffic using wireshark, and though it is not very clear, it seems that the freezing incident might occur if an incoming frame arrives right at the time the ESP32 is sending one.
Is there a bug in the ESP32-AT firmware? or an incorrect configuration on my part?
Notes:
1- I am trying to debug the library that controls the ESP32 using SPI-AT. This library was written by the soldered company (www.soldered.com) for the product Inkplate 6Motion that is a eink display with wifi connectivity. I did not design nor write this code and have a limited analysis tooling.
2- I found in this forum someone seemingly having a similar case, but I found no follow-up of his problem. The reference is :
I have a project which is a wireless remote control for driving a real boat. Its main processor is a STM32H7 and it is fitted with a ESP32-C3 running SPI-AT as a coprocessor to handle wifi communication, and it communicates with the boat system using repeated UDP frames back and forth.
The remote sends a 22 byte binary frame, to which the boat responds a 44 byte binary frame, and this is repeated about 3 times a second.
I notice freezes that completely stop the traffic in such a way that the only remedy I found is resetting the ESP32 and re-configuring it, but this takes way too long and is not acceptable in the context of driving a boat.
The problem occurs in the sending process. It works a follows (seen from the STM32H7):
{
Send command "AT+CIPSEND=%d\r\n"
Wait for handshake pin for max Timeout1 (200 ms)
Get the response
Check if response is "\r\nOK\r\n\r\n>"
Send the payload part (here, a 22 byte array)
Wait for handshake pin for max Timeout2 (600 ms)
Get the response
Check if response is "\r\nOK\r\n"
}
After a few hours of exchanging 3 messages per second, the system freezes. In one example, it froze after more than 27,000 exchanges. What happens is that the second waiting for handshake takes more than the timeout value. Initially this would put my system in an error state, but I noticed that then the UDP frame was sent anyway. I then decided to just ignore the timeout, so that the operation continues normally. This incident can occur several times (tens of times) without any problem. But eventually, something different happens.
This time, the frame is not sent when the timeout2 occurs. Since the event is ignored, there will be a next time attempting to send a UDP frame, but this time, the process fails at Timeout1. From that time on, not only the ESP32 cannot send frames, but the frames it receives are not detected nor read. So the traffic completely stops, and so far my only choice is to reboot the remote control.
I have measured statistics of the time taken for the handshake pin to be activated. Here is the result. The graph shows the values sorted by increasing values.
One can see that about half the values range from 230 to 300 ms, then about a third of the values are remarkably constant at about 370 ms, then a new step to a value of about 570 ms, and then a few values above, including infinity.
What could be the cause of this problem?
I have analysed the traffic using wireshark, and though it is not very clear, it seems that the freezing incident might occur if an incoming frame arrives right at the time the ESP32 is sending one.
Is there a bug in the ESP32-AT firmware? or an incorrect configuration on my part?
Notes:
1- I am trying to debug the library that controls the ESP32 using SPI-AT. This library was written by the soldered company (www.soldered.com) for the product Inkplate 6Motion that is a eink display with wifi connectivity. I did not design nor write this code and have a limited analysis tooling.
2- I found in this forum someone seemingly having a similar case, but I found no follow-up of his problem. The reference is :
Re: [ESP32 AT Firmware] Module Stops Responding After Several Hours of Stable Operation
Thanks
Postby amir.shn ยป Thu Oct 16, 2025 8:22 pm