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

Her Mary
Posts: 472
Joined: Mon Oct 27, 2014 11:09 am

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

Postby Her Mary » Wed Nov 25, 2020 11:54 am

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

Posts: 2
Joined: Sat Nov 21, 2020 9:58 pm

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

Postby StefanS » Mon Dec 07, 2020 9:25 pm

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 version: 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

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


> 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\0\0
Recv 101 bytes



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.

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.

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.


Who is online

Users browsing this forum: No registered users and 4 guests