ESP32 Forum

Hi all,

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!

Hi Aldrin01392,
Could you please provide more details to see what happened? For example, Could you please visit https://github.com/espressif/esp-at/act ... 7453872398 and download `esp32-wroom-debug-at` this firmware, and have a test. the AT log port should output a lot of logs. please use serial tool to save them with timestamp. This is the direct way to analyze your issue.

Some reply for your questions:
1. Has anyone experienced a similar long-duration TCP issue with AT firmware?
Before each AT release, we systematically test the AT functionality with a large number of testcases for over a week and have not found any issues similar to yours.

2. Is there a known memory leak, socket timeout, or stack overflow issue in v3.4.0.0 under these conditions?
- AT+SYSRAM? command to query memory state. btw, if alloc failed, the AT log port should output `alloc failed, size:<requested_size>, caps:<requested_cap>`
- You can configure the TCP send timeout via the AT+CIPTCPOPT command: https://docs.espressif.com/projects/esp ... cmd-tcpopt

3. Would enabling AT+CIPSTATE monitoring or resetting the connection every few hours help prevent this?
I don't think AT+CIPSTATE can do anything for your case. resetting the connection is not a good way to figure it out.

4. Are there any recommended watchdog or keep-alive mechanisms for long-running TCP sockets in AT mode?
- AT firmware already has multiple watchdogs built in. These include interrupt watchdog, task watchdog, and hardware watchdog. You can search `WDT` in sdkconfig file
- You can configure the TCP keep-alive via the AT+CIPTCPOPT command: https://docs.espressif.com/projects/esp ... cmd-tcpopt

Hi Aldrin01392,

I am having exactly the same issue with the UDP connection, i am sending data from my main MCU which is a STM32H7 to the esp32-s2 solo at a sampling rate of approximately 20Hz.I receive busy p... once in a while after an hour and the ESP32 chip becomes completely unresponsive after about 3 hours.

Please let me know if you have found any solution for this issue.

Thanks.

Amir

Hi @amir.shn , could you please help debug it according to the comments i posted above.