I'm working on a project using ESP32 running AT firmware (v3.4.0.0). The module is connected to a host MCU (STM32) and communicates via UART using AT commands.
The use case is simple:
The ESP32 connects to a Wi-Fi network using AT+CWJAP,
Then opens a TCP connection using AT+CIPSTART,
And continuously sends data to a remote server using AT+CIPSEND.
This runs repeatedly at a fixed interval (once every few seconds), for many hours.
The issue we are observing is quite strange:
Everything works perfectly for 6–8 hours, with consistent successful sends and replies from the server. But after a random time in this range, one AT+CIPSEND response breaks mid-way, and after that, ESP32 becomes completely unresponsive to further AT commands. No error is returned, just a complete stop of replies from the module. Echoing shows that the last command was sent properly from the MCU side, but ESP seems stuck or not processing any new command.We have verified that:
The power supply is stable.
No overlapping or malformed commands are sent.
Flow of data is consistent and within acceptable rates.
We are not using multiple connections (AT+CIPMUX=0).
It feels like the TCP socket or internal state of ESP32 enters an unrecoverable state after many hours of operation.
---
Questions:
1. Has anyone experienced a similar long-duration TCP issue with AT firmware?
2. Is there a known memory leak, socket timeout, or stack overflow issue in v3.4.0.0 under these conditions?
3. Would enabling AT+CIPSTATE monitoring or resetting the connection every few hours help prevent this?
4. Are there any recommended watchdog or keep-alive mechanisms for long-running TCP sockets in AT mode?
---
Any advice, pointers, or suggestions are welcome. Thanks in advance!
