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

[jimyates]

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?

[pratik]

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.

[jimyates]

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

[pratik]

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.

[jimyates]

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

[miky_boy]

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

[Her Mary]

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

[andreysnug]

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

[jimyates]

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!

[StefanS]

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