I’ve set up an ESP8266 as a socket server and an android app with a couple of buttons to turn a light on and off… no problem. If you press the buttons continuously as fast as possible, most of the time everything is fine but eventually the ESP8266 will lock up after returning a “busy s…” signal. Incidentally I’ve tried this with the unit operating as a router – or simply logging into my main WIFI router. Result is the same – both work well but the former is a pain if the thing locks up as the reset kills the internal router.
Amazingly, the only way out of this is with a hard reset – that is not the command but holding the reset button down for a half second and release.
As of yesterday there IS an update which takes us part way there… we’ve been provided us with not only the latest FLASH update but additionally an AT+XRST command. If you use this update you will likely find your default baud rate set back to 9600 initially. You need to use AT+XIPR=115200 if for example your working baud rate is 115200. That is stored in EPROM and survives reset/power cycle.
Here’s the link for the update..
http://www.esp8266.com/viewtopic.php?f=6&t=294&sid=ce984d8af7dcffbc6d5e8710d242296f&p=1719#p1719
Another article suggests adjusting the timeout as below…I’ve not yet tested to see if that gets one out of every situation… let me know if you have any success with this.. It HAS gotten me out of most situations up to now.
AT+CIPSTO=60 Sets the socket timeout period to 60 seconds
AT+CIPSTO? gets the current timeout value
If you install the latest update and are unsure you can go back to the 0922 software here … http://www.electrodragon.com/w/Wi07c
Incidentally the only change you have to make to wiring to blow the firmware is to take the GPIO0 line (the upper left green line in my diagram) and ground it. Cycle the power as it does not know it’s in programming mode until you do that… run the update software on the BIN file and you’ll see it updating.. I’ve had this work even when the whole board has gone heywire due to a bad update… when you get there – in my case it says it’s not coming out of update mode – ignore that, reconnect the GPIO0 line as normal and reboot – it will initially power up at 9600 baud and you can use the relevant command to put it back to whatever you use – 115200 in my case. AT+CIOBAUD? Tells you the current baud rate, to set the baud rate you can use AT+CIOBAUD=9600,19200,38400,57600,74880,115200,460800, 921600
Click on the image above right to enlarge.
None of this really sorts the BUSY problem…. but for example with the CIPSTO set to 10 seconds – I have on and off buttons on an Android App and a status indicator updating every 1/2 second (state of the lamp). It is working and if it screws up – that timeout gets me out of it – UP TO NOW…
My Tech Weblog 
To get a hardware reset, I use an NPN transistor or N-channel MOSFET with the ESP8266 ground wire.
Works well controlled by Arduino pin. I send AT command to ESP8266 every 13 seconds if “OK” not found reset and reconnect. My web page refreshes every 122 seconds so no conflict with the check and refresh times.
Not a firmware fix, but works.
Hi 2 resistors will do… Assuming you are using g a 5v processor.
I’ll clarify that – from the PIN on Arduino – a 560r resistor to the reset on the WIFI board and from there a 1k2 to ground. That should more or less keep the voltage in the safe area.. I’ve done this also with serial input…
I have been getting a lot of “busy” also, however, I have yet to update my firmware. What version are you currently running that is giving you the same headache?
Hi – the version I’m using SAYS 0018000902 – but I installed it manually and I think it’s supposed to be 0018000922 – as you can see miles ahead of others (except the one guy who says he’s fixed the BUSY issue and I can’t find his code)….
I’m using the transistor to power the module, as grounding the reset and/or the CH_PD pin doesn’t always seem to work for me. Also using a CD4050 for 5V/3.3V shift. Rebooting the module and reconnecting to router works fine.
Thanks for that Jason. I’ve not found the need to ground the CH_PD pin yet which I keep tied to 3v3. The reset pin responds well to the resistive divider but of course either mechanism is fine. Indeed with my current setup (5v processor, dividers to power the input line and reset line) all works well and reliably EXCEPT when you overdo it and end up in this “busy” mode – out there on the web there are hints that “busy” is causing issues for others to so I will keep an eye open for updates to tackle this.. A fellow called Rudi has a video here (https://www.youtube.com/watch?v=WFo4Fs0p_NY) with some kind of test tool (which unless I’m missing something sadly he does not share but he too indicates there is a problem with busy – and sending things too fast to the module?? He suggests in the comments that he might make his Windows tool available but I’m not seeing the link… For the latest firmware that I’m AWARE of – go here… http://www.electrodragon.com/w/Wi07c (see down at the bottom).
Hi There,
Have you tried to use the module in “transparent mode” to see if that fixes your busy problem. I believe CIPMUX=0 and then CIPMODE=1. Then when you do your CIPSEND, you don’t have to indicate the length of the sent string. After sending your string, you do a pause and issue a +++ without a cr/lf. Then you will be back in command mode.
I have been using this with no problems for a while. Hopefully it may help you also.
Also, in your post you show this… AT+XIPR=115200
I thought that it was AT+CIOBAUD=115200. Can you tell me what the XIPR is.
Thanks
Jim
Here is a video of the +++ thing
I’m going to try your version right now… when you say pause.. what length of pause? As for the commands – if you look I have done a firmware upgrade, the fellow that has done the upgrade wanted to leave total backwards compatibility so any new or enhanced commands he’s made different.. all of that works fine…. Ok, please come back on that delay – meanwhile I’m off to give it a shot – good timing as 2 more boards just turned up from China so I can afford to be a bit more ambitious 🙂
I used one second before and one second after. I highly doubt that this amount of time is required, but I haven’t had the opportunity to test that. Also, you will find that when you are receiving data back to the module, in this mode, that you won’t get the +IPD response anymore, which I think is great. In this mode, when you issue the cipsend, you will still get the > . You might want the test this using just a terminal program to see how it reacts. Thanks for keeping us posted.
Any word on the AT+XIPR=115200 thing?
That didn’t quite work for me – not sure I follow your CIPSTART command.. Assuming my IP is 192.168.0.7 – how do I start a SOCKET LISTENER… so I would use CIPMUX=1 and then AT+CIPSERVER=1,4000 would start it listening on port 4000 for incoming commands – that FAILS if you set CIPMUX=0
I could have sworn I replied on the XIPR – if you follow my latest blog (same place) I refer to a new upgrade I installed in the early hours. The guy who did the upgrade did not want to interfere with normal commands so made his different for backwards compatibility. Ok, so take me through the sequence of the socket listener setup (you would not specify an IP address – just the port to listen on)…. and thanks for this!!!
I may have confused the situation. I am not familiar enough with socket listener. What I did was to send a GET to wunderground.com and get a very long json response. I did the cipmux=0, cipmode=1, cipstart with the ip and port for wunderground api, cipsend the Get, +++ out of that, receive long json response. So I think that I am not doing what you are doing. I apologize for the confusion.