esp-at
esp-at copied to clipboard
espressif
Receiving +IPD line when AT+CIPRECVLEN? command is still active
I've been performing tests with manual receiving of data on an ESP32. During my tests I noticed that +IPD lines (for incoming data) are coming in while an AT+CIPRECVLEN? request is still being processed. This leads to confusing situations. See the example below (UART @ 2000000 Baud):
+IPD,4,424
AT+CIPRECVLEN?
+CIPRECVLEN:-1,-1,-1,-1,424
OK
AT+CIPRECVLEN?
+CIPRECVLEN:-1,-1,-1,-1,424
OK
AT+CIPRECVDATA=4,424
to read 424 bytes
+CIPRECVDATA:424,"185.xx.xx.xx",80,ijklmnopqrstuvwxyz!@#$%^&*()_+<>,.;'"[]{}
0001952300:ABCDEFGHIJKLMNOPQRSTUVWXYZ`1234567890-=abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+<>,.;'"[]{}
0001952400:ABCDEFGHIJKLMNOPQRSTUVWXYZ`1234567890-=abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+<>,.;'"[]{}
0001952500:ABCDEFGHIJKLMNOPQRSTUVWXYZ`1234567890-=abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+<>,.;'"[]{}
0001952600:ABCDEFGHIJKLMNOPQRSTUVWXYZ`1234567890-=abcdefghijklmnopqrstuvwxyz!@#$%^
OK
AT+CIPRECVLEN?
+IPD,4,2872
+CIPRECVLEN:-1,-1,-1,-1,0
OK
See the last 4 lines. The line +IPD,4,2872 is sent by the ESP32 while it's still processing the AT+CIPRECVLEN? request.
In my opinion the response to theAT+CIPRECVLEN? should either reflect the new data or the +IPD,4,2872 should come after the response.
See this issue on the ESP_AT_Lib repository for more info and background.
Hi @PowerfulCat, I'm not sure how I should interpret your comment. In my case I'm using AT+CIPRECVMODE=1. This is "passive mode" which I refered to as "manual receiving of data". In your comment you seem to refer to AT+CIPRECVMODE=0 which is "active mode".
See here for details: https://github.com/espressif/esp-at/blob/master/docs/ESP_AT_Commands_Set.md#cmd-CIPRECVMODE
The root reason is
AT+CIPRECVLEN? ------- the command echo, in AT recv task
+IPD,4,2872 ------- socket task
+CIPRECVLEN:-1,-1,-1,-1,0 ------- the command execute, in AT process task
OK
We can ensure +IPD,4,2872 and +CIPRECVLEN:-1,-1,-1,-1,0 cannot be interrupted
How can we make sure echo cannot interrupt workflow of tasks and make sure that +CIPRECVLEN response will return same as +IPD did just before?
How can we make sure echo cannot interrupt workflow of tasks and make sure that +CIPRECVLEN response will return same as +IPD did just before?
ask again CIPRECVLEN and it will return the new count of available bytes
@jandrassy this is not a solution. @xcguang do you guarantee that if ECHO is disabled, command will work just fine?
AT+CIPRECVLEN? ------- This is what I send, not echo from ESP
+IPD,4,2872 ------- socket task
+CIPRECVLEN:-1,-1,-1,-1,2872 ------- the command execute, in AT process task
OK
Will it be like this then? Or can it still happen similar to previous case?
As to me it is unclear. Seems that you construct your response message before you lock mutex to accessing AT port. You should first lock mutex, then construct full response & send OK/ERROR, later release it.
While command is executed (or in progress), nothing else could be printed to the AT port. This would then guarantee right data at any moment.
even the esp8266 NonOS SDK AT firmware can and does 'pop up' notifications in between command/query response lines. if you use the passive mode and test the available data with AT+CIPRECVLEN? then ignore +IPD. while the link is not closed check for available data with AT+CIPRECVLEN?. some weeks ago before the esp32 2.0 release this AT firmware was worse. it was like
AT+CIPRECVLEN? ------- the command echo, in AT recv task
+IPD,4,2872 ------- socket task
4,CLOSED
+CIPRECVLEN:-1,-1,-1,-1,0 ------- the command execute, in AT process task
OK
this caused in my library to stop polling CIPRECVLEN for link 4, since it closed on CLOSED notification