AT+CIPRECVLEN issue in UDP mode and passive receive mode

[arturv2000]

Answers checklist

• I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
• I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

AT+GMR

AT+GMR
AT version:4.2.0.0-dev(098bc1a - ESP32C3 - Sep 11 2025 03:22:47)
SDK version:v5.4.1-643-g8ad0d3d8f2-dirty
compile time(879bb20):Sep 26 2025 16:02:25
Bin version:v4.2.0.0-dev(MINI-1)

OK

This is a custom version, based on current "master", but the issue also exists in release version for ESP32C3

ESP-AT Firmware Source

Compile ESP32 AT locally cloned from Master. Issue also exist in release version for ESP32C3

Hardware Information

ESP32C3 MINI 1 Module

Power Supply used

External 3.3V

What is the expected behavior?

When reading data from socket (in passive mode) using AT+CIPRECVLEN and in UDP mode, a partial frame read should be supported, as is in TCP mode. As is at the moment if we receive an UDP frame with 500 bytes but want to make partial reads of 100 bytes is not possible, after the first partial read the entire frame/buffer is released.

What is the actual behavior?

When using UDP Communication, and receiving data via AT+CIPRECV_LEN=<idx>,<len> the expectation is that this command allow us to read partial data from the UDP receive buffer.

The ESP correctly sends the notification +IPD:<idx>,<len> indicating that some data has arrived, and subsequent the processor is requesting the ESP for an update on how many bytes exist to be read

+IPD,1,444
AT+CIPRECVLEN?
+CIPRECVLEN:0,444,0,0,0

OK

After that I am going to read parcels of for example 100 bytes, ESP correctly answer with only 100 bytes but it clears the entire frame that may have received

+IPD,1,444
AT+CIPRECVLEN?
+CIPRECVLEN:0,444,0,0,0

OK
AT+CIPRECVDATA=1,100
+CIPRECVDATA:100,"192.168.125.255",9797,Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore 
OK
AT+CIPRECVLEN?
+CIPRECVLEN:0,0,0,0,0

OK

As seen, after the first read of 100 bytes, the ESP reports that there are no more data to read (although 444 bytes have arrived in a single frame).

If multiple frames exists in the reception buffer the same thing happen, a single read can read data from more than one frame but the last frame that may have been sent incomplete is deleted...

+IPD,1,444
AT+CIPRECVLEN?
+CIPRECVLEN:0,1332,0,0,0

OK
AT+CIPRECVDATA=1,1000
+CIPRECVDATA:1000,"192.168.125.255",9797,Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborumLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna 19:42:23.350> aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborumLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore ma
OK
AT+CIPRECVLEN?
+CIPRECVLEN:0,0,0,0,0

OK
AT+CIPRECVDATA=1,1000

ERROR

In this case, three UDP (444 bytes) frames were sent to the ESP...

In TCP Mode it seems to operate correctly.

Probability of recurrence

My firmware is handling 4 socket connections, two TCP and two UDP (one UDP is TX/RX and the other is just TX), multiple devices can be connected to the HotSpot sending data via UDP and due to time to process all data from other sockets (or due to memory operations like Sector erases that take a considerable time), occasionally when reading UDP data this situation happens since in 200~300ms multiple devices may have sent UDP Data...

AT+SYSRAM?

at+sysram?
+SYSRAM:108964,73948
OK

Steps to reproduce

1. Set AT+CIPMODE=1
2. Set AT+CIPRECVMODE=1
3. Set AT+CIPDINFO=1
4. Set AT+CIPMUX=1
5. Create HotSpot and connect PC to it
6. Connect to a WIFI Network
7. Create a UDP Socket AT+CIPSTART=3,"UDP","192.168.125.255",4000,4000,0,"192.168.125.10"
8. From PC send multiple UDP frames data to ESP and do not read immediately when frame arrives (when the first +IPD URC appears)
9. Attempt to read using AT+CIPRECVLEN making partial reads (len < UDP Frame size)

AT command port output

20:03:54.725> +IPD,1,444
20:03:58.106> AT+CIPRECVLEN?
20:03:58.106> +CIPRECVLEN:0,2664,0,0,0
20:03:58.106> 
20:03:58.106> OK
20:03:58.546> AT+CIPRECVDATA=1,1000
+CIPRECVDATA:1000,"192.168.125.255",9797,Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborumLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna 20:03:58.664> aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborumLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore ma
20:03:58.664> OK
20:03:58.664> 
20:03:58.664> +IPD,1,1332
20:03:59.350> AT+CIPRECVDATA=1,1000
+CIPRECVDATA:1000,"192.168.125.255",9797,Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in 20:03:59.424> reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborumLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborumLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore ma
20:03:59.424> OK
20:04:01.787> AT+CIPRECVDATA=1,1000
20:04:01.787> 
20:04:01.787> ERROR
20:04:02.223> AT+CIPRECVDATA=1,1000
20:04:02.223> 
20:04:02.223> ERROR
20:04:02.725> AT+CIPRECVDATA=1,1000
20:04:02.725> 
20:04:02.725> ERROR

AT log port output

20:03:58.585> I (2566965) at-net: to read 1000 bytes
20:03:59.337> I (2567751) at-net: to read 1000 bytes
20:04:01.772> W (2570173) at-net: no data
20:04:02.210> W (2570607) at-net: no data
20:04:02.711> W (2571092) at-net: no data

More Information.

It seems that a possible workaround would be to use the value from +IPD URC to read only that amount, and wait for subsequent +IPD URC to make sure we read frame by frame. But even so, it seems to defeat a bit the purpose of AT+CIPRECVLEN command. And my biggest issue with this process, is that i personally don't trust URC codes too many problems with some uncertain behaviours in GSM/LTE modems to trust just in URCs...

If this behaviour is expected in UDP mode, please add a note about this in the docs related to AT+CIPRECVDATA.

[arturv2000]

IT seems that #451 is related to this, if the implementation mentioned here was really implemented (specially point 1, +CIPRECVLEN in passive mode must report the size only of the next pending UDP message would facilitate this...