ESP8266 Developer Zone

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

2020-12-07T21:25:57+08:00

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:

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:

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

Statistics: Posted by StefanS — Mon Dec 07, 2020 9:25 pm

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

2020-11-25T11:54:07+08:00

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

Statistics: Posted by Her Mary — Wed Nov 25, 2020 11:54 am

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

2020-11-21T22:58:14+08:00

Hi all,

this is an old post but I am wondering if the original problem has ever been resolved?

I seem to have the same or a very similar problem: I am using AT+CIPSENDEX with max 2048 Buflen but always terminate the transmission before by sending \0. Each \ in the transmission payload is escaped, i.e. send as \\.

This works very nice most of the times. But also for me sometimes the \0 is not recocnized as a termination and the ESP waits for further characters and my external processor waits for the send ok response from the ESP...

After finding this post, I have tried sending another \0 sequence under such conditions and that always started the transmission of all my payload characters but including the original \0. I have also checked with a logic-analyzer that the sequence was send correctly without gaps. In the failing cases no \ characters are in the payload and the final \0 sequence was always preceeded by a space.

Any suggestions?

Regards
Stefan

Statistics: Posted by StefanS — Sat Nov 21, 2020 10:58 pm

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

2018-05-26T05:03:33+08:00

When sending AT+CIPSENDEX command, you terminate the command by sending the characters \0
BUT
if you are sending the \0 in a string by using a print type function, you MUST send "\\0", NOT just "\0". The first \ means that the second \ is to be sent as a literal character.
AND
if you are sending the \0 by just sending bytes to the wroom, you do NOT need to send two \'s, just send byte(0x53) and byte(0x30).

I hope this helps you!

Statistics: Posted by jimyates — Sat May 26, 2018 5:03 am

"0" command SOMETIMES does not terminate ATCIPSENDEX transmission

2018-05-25T07:08:03+08:00

Hello. With the latest update, I do not work in 888 HUD їanyone with the same problem and can help me? Thank you.

Statistics: Posted by andreysnug — Fri May 25, 2018 7:08 am

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

2018-02-23T11:44:35+08:00

There is a simple example may help you https://bbs.espressif.com/viewtopic.php?f=61&t=560.

Statistics: Posted by Her Mary — Fri Feb 23, 2018 11:44 am

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

2018-02-17T09:35:26+08:00

Hi my friend,

I'm having the same problem i'm using a microcontroller to send AT commands to the ESP8266 module and i spend a lot of time to try sending the HTML package.

I used Wireshark to investigate the HTML header and the CR LF doesn't work. I see the header with ...\r\n but for the HTML header isn't a CR LF.

You fixed your problem? Or anyone have any idea to fix this?

Thanks and regards

Statistics: Posted by miky_boy — Sat Feb 17, 2018 9:35 am

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

2016-09-21T19:35:23+08:00

Pratik,

I'm not developing on the ESP8266, I'm using another processor and communicating with the ESP8266 using AT commands. Right now I don't want to develop on the ESP8266, I am trying to use it as an "out of the box" product, ready to go.

I used the AT+CIUPDATE command to update the firmware over the air. As I understand it, this goes to the Espressif server to update the ESP with the latest firmware, which should be created with the latest SDK. Isn't it? If not, why not? If I have the latest "firmware", but not the latest SDK, how do I update the SDK?

Jim

Statistics: Posted by jimyates — Wed Sep 21, 2016 7:35 pm

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

2016-09-21T11:00:04+08:00

Hi Jim,

The SDK version you are using is like months old and had a lot of things that were not very reliable. You could use 1.5.3 or 1.5.4, but the latest one based on SDK v.2.0.0 is available on Espressif page for ESP8266:
http://www.espressif.com/products/hardware/esp8266ex/

I am not able to reproduce your problem on this AT command firmware (based on SDK v.2.0.0) and so you should try it as well! And if you still face issues, let me know so I will forward the issue to the core developers.

Statistics: Posted by Guest — Wed Sep 21, 2016 11:00 am

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

2016-09-20T01:21:37+08:00

Pratik,

Thank you for your response.

First, sorry, I had a typo in my original post, but not my code. I am ALWAYS sending "\0", not "/0". ("/0" would NEVER be accepted as a terminate instruction, so would never work)

Second, my "\0" is ALWAYS preceded by a Carriage Return, Line Feed, so I always send the 4 byte sequence 0x0D, 0x0A, 0x5C, 0x30 and I have verified with an oscilloscope that there is no delay between the characters. Further, I have verified with the oscilloscope that the specific 0x0D, 0x0A, 0x5C, 0x30 that was not recognized as the terminate instruction by the ESP8266 was, in fact, the byte sequence 0x0D, 0x0A, 0x5C, 0x30 with no delay between characters. So, I am never sending "\\0".

Third, here is the result of the AT+GMR? from my ESP8266:

AT version:0.52.0.0(Jan 7 2016 18:44:24)
SDK version:1.5.1(e67da894)
compile time:Jan 7 2016 19:03:11

Thanks for your help.

Jim

Statistics: Posted by jimyates — Tue Sep 20, 2016 1:21 am

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

2016-09-17T20:28:00+08:00

Hello,

You should take care that the character "\0" is not preceded by a '\'. Because that is how you tell the ESP8266 firmware to treat the "\0" sequence as "data to be sent" and NOT "command".

And you wrote "/0", isn't it supposed to be "\0"?

Also, could you please specify the command set using AT+GMR? "Latest" firmware on your device might not be the latest available in terms of SDK, depending on what updates have been officially posted by the update team.

Statistics: Posted by Guest — Sat Sep 17, 2016 8:28 pm

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

2016-09-17T02:03:37+08:00

I am using a WROOM-02 with ESP8266. I have updated the firmware of the ESP8266 over the air to the latest version of the firmware on 9/5/2016. I am communicating with the Wroom using the USART at 115,200 baud. I am using UDP protocol to send strings of data over the wifi.

After sending the command "AT+CIPSENDEX=0,2000" to the ESP8266 (Wroom-02), receiving the ">" response from the ESP8266, and sending the data (varying length from 32 to 1800 characters), the "\0" character combination is sent to tell the ESP8266 that there is no more data to follow, and it should send the data it has received. In every case, a CR LF (0x0D, 0X0A) is sent immediately before the "\0" command.

When the frequency of data transmission is low (1 or 2 transmissions per second), the "\0" is always recognized by the the ESP8266 as a command to terminate the transmission, and the ESP8266 returns "xxx bytes sent SEND OK".

When data transmission frequency is increased, the ESP8266 will usually recognize the "\0" as a command, but will also regularly NOT recognize it as a command to terminate the send, and accept it as characters to be passed via wifi transmission. When the "\0" is not recognized as the command to terminate transmission, it is necessary to send a CR LF followed by the "\0" command again in order to have the ESP8266 terminate the transmission. Unfortunately, this also results in the ESP8266 sending the first "\0" and the "CR LF" over the wifi, which disrupts the data being sent.

On very rare occasions, the second "/0" that is sent is also not recognized as a command to terminate, and it is necessary to send a third "CR LF \0"

I have validated, using an oscilloscope, that the "CR LF /0" (0x0D, 0x0A, 0x5C, 0x30) are received at the correctly at the Wroom without any delay between characters. This is true of both the initial "/0" that is not recognized as a command, and the subsequent "/0" that is recognized. It is also clear that they were received by the ESP8266 because they are subsequently sent over the wifi!

I believe that this is a bug in the ESP8266 firmware.

How can I ensure that when the ESP8266 is more heavily loaded, that the "\0" command will be recognized and terminate the CIPSENDEX initiated transmission?

Statistics: Posted by jimyates — Sat Sep 17, 2016 2:03 am