"\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

[Her Mary]

Maybe you can help a try with the latest RTOS AT. https://github.com/espressif/esp-at

[StefanS]

Hi all,

first let me add some more details on my configuration:

I am using an ESP-01 and I am communicating with 19.200 Baud. I have done an Over-The-Air OTA Update a few months back. And the software release is:

Code: Select all

AT+GMR
AT version:1.7.4.0(May 11 2020 19:13:04)
SDK version:3.0.4(9532ceb)
compile time:May 27 2020 10:12:20
Bin version(Wroom 02):1.7.4
OK


In the meantime, I did some more trials and found that missing the \0 as an termination marker depends on the length of the buffer. Specifically it always failed when the buffer length ends on 99 in decimal writing, e.g. for 99, 199, 299, and so on!
A simple example is shown in the following log:

Code: Select all

AT+CIPSENDEX=2048

OK
> 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\0\0
Recv 101 bytes

SEND OK

+IPD,101:123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\0


The receiving end of this link is configured to send back a verbatim copy of what it has received. So it can be seen that the first \0 is not recognized as termination but is included in the payload, which becomes now 99+2=101 bytes. (When I do not sent the second \0, the communication gets stuck.)

When sending massive amounts of messages with different length, I have found that sometimes also at length xx00 (100, 200, 300..) and very rarely also with lengths xx98 and xx01 the \0 can be missed as a termination.

WORKAROUND:
For now, I have implemented a byte counter and when at the end of the message the length is ending between xx97 and xx02 (inclusive), I am adding 0x00 (NUL) bytes until the message length reaches xx03 before sending the \0. In my application (an http server), the receivers can silently ignore the additionally received 0x00 bytes.
So far, I have not seen any more issues when using this workaround.

QUESTION:
Can anybody reproduce this problem? I doubt that it is directly related to the number of bytes, but at least for me (e.g. with my baud rate etc.) it shows this peculiar behavior.

Regards,
Stefan