ESP8266 Developer Zone

Re: AT+CIPSTART does not end with OK or ERROR

2015-06-08T20:04:40+08:00

Hi,

In your case, you could send command "AT+CIPSTART=1,"TCP","XXX.XX.XXX.XX",8183" after got response "Recv 242 bytes"

Or you could just check what is received on the TCP server, to find out if "AT+CIPSTART=1,"TCP","XXX.XX.XXX.XX" to be a part of TCP data.

"busy s.." here may because that with "AT+CIPSTART=1,"TCP","XXX.XX.XXX.XX" data length is longer than 242 bytes, then the longer part will be considered as a new command.

Thanks for your interest in ESP8266 !

Statistics: Posted by ESP_Faye — Mon Jun 08, 2015 8:04 pm

Re: AT+CIPSTART does not end with OK or ERROR

2015-06-03T20:35:31+08:00

Hi Faye,

We dont think AT+CIPSTART=1 is part of the 242 bytes. Our MCU send out the 242 bytes of data first before sending AT+CIPSTART=1. Since SDK 1.1.0 removed the echo of the 242 bytes, we can't tell what is being received. If the AT+CIPSTART=1.... is not valid, we should not see a "busy s..." right? It should be ERROR since if AT+CIPSTART is part of the 242 bytes, then the remaining data will not form a valid command.

We are guessing also why SDK 1.1.0 removed the echo for data to be transmitted (the 242 bytes) since SDK 1.0.1 echo those data. Our guess is that other messages can be injected (which is not suppose to) during the echo as seen in some of our logs with SDK 1.0.1. We have stop using SDK 1.0.1 because of this.

e.g. we want to send "ABCDEFG"

AT+CIPSENDBUF=0,7
20,19

OK
>ABCD
1,CLOSED <---- mesages inserted into echo, making it difficult to skip echo data
EFG

As for AT+CIPSTART does not end with OK or ERROR, we are ok with it since we treat "busy s..." as the end.

Thanks and best regards,
Hew

Statistics: Posted by hhc — Wed Jun 03, 2015 8:35 pm

Re: AT+CIPSTART does not end with OK or ERROR

2015-06-03T10:31:31+08:00

Hi，

Code:

AT+CIPSENDBUF=0,242
20,19

OK
> AT+CIPSTART=1,"TCP","XXX.XX.XXX.XX",8183
busy s...

Recv 242 bytes

0,20,SEND OK

It seems that “AT+CIPSTART=1,"TCP","XXX.XX.XXX.XX",8183” is considered as a part of data “AT+CIPSENDBUF=0,242” sent.

This might happen if you are not using UART flow control, UART may lose data, so there are not enough 242 bytes, then the next AT command may be considered as a part of the 242 bytes, the data waiting to send.

Statistics: Posted by ESP_Faye — Wed Jun 03, 2015 10:31 am

AT+CIPSTART does not end with OK or ERROR

2015-06-02T16:43:11+08:00

Hi,

As seen in the log below, sometimes AT+CIPSTART returns "busy s..." without ending with ERROR and OK. Does "busy s..." indicate the end of AT+CIPSTART processing by ESP8266? (so that we dont wait for OK or ERROR as mentioned in documentation). Should there be any delay between AT+CIPSENDBUF and AT+CIPSTART ?

In the log we see that "Recv 242 bytes" is send out by ESP8266 after AT+CIPSTART, but we already send 242 bytes before we send AT+CIPSTART.

SDK is v1.1.0.

IP address has been commented out in log.

Regards,
Hew

AT+CIPSTART=0,"TCP","XXX.XX.XXX.XX",8184
0,CONNECT

OK
AT+CIPSENDBUF=0,242
20,19

OK
> AT+CIPSTART=1,"TCP","XXX.XX.XXX.XX",8183
busy s...

Recv 242 bytes

0,20,SEND OK

+IPD,0,322:HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-H: GYrPC2fr/gGPSdjTYN9HMxbA31I=
Content-Type: text/plain
Content-Length: 138
Date: Tue, 02 Jun 2015 08:10:44 GMT
Connection: close

a83d563f|1BD3|b24e4|28eeca39|/fw/5c8e60949772614a2f776bddf2b2f721cd71dcd0.4295004598|c4qIr3LpTDLpJ1Ur09bZyy0dshA=|k4qT0YKG4ZVzeMZVtnZi8Q==0,CLOSED

Statistics: Posted by hhc — Tue Jun 02, 2015 4:43 pm