ESP8266 Woes… a Ray of Light

tmp7BABSo I’ve been continuing to test the Espressif (manufacturer) ESP8266-based WIFI module called the ESP-01 and I’m starting to get somewhere with the “busy s” problem. This board is the more common of a few variations of the board and has power, ground, transmit, receive and 4 control lines called GPIO0, GPIO2, CH_PD and RST. The board runs on 3v3 and consumes up to 250ma (note that some of the smaller Arduino-type boards which have 3v3 power supplies internally, cannot supply this much current. Better to use a 3v3 regulator capable of handling much more. I use one on my home-made Arduinos which can handle up to 1 amp.

Some more hardware info – the pins are not 5v tolerant… clearly the output TX can be connected directly to a 5v Arduino input but you need level conversion for output from Arduino to the WIFI board. I use a resistive divider. 560r from the Arduino output to the WIFI input and 1k2 from there to ground. In normal use including programming you only need 2 of these dividers. This fellow gives a lot more info on hardware.

I’ve done some in-depth tests with an Android mobile phone (Samsung S4)  sending commands to the board over a WIFI TCP socket (using NETIO) – and monitored what happens (I use a 1284-based board so I have 2 serial sockets – AWFULLY handy for testing but you could do similar with a bog-standard Arduino). While the phone was sending polling commands constantly, all was working well, until I swapped apps on the phone (or shut it down or had an issue with WIFI signal)  in which case it might only get part way through sending the command.

You CANNOT avoid this happening with WIFI by the very nature of it being wireless, there might be a glitch, might be a lack of signal momentarily, interference etc., there will always be occasions when you lose data.

Rather than recover gracefully, the ESP8266 (I imagine) has a flag set to say it is in mid-command… as it pulls in data. A new command coming in is NOT clearing that flag (this is a sheer guess) and so no matter what you do it will just say “busy s” until you reset. One kind gentleman has added a blanket reset command to the ESP8266 but that’s not the answer as you then have to wait for the reset and set up your modes again – what’s needed is for the designers to fix this bug.

SO yesterday afternoon I wrote to them, not very hopeful as I figured they’d be Chinese and might not even understand what I had to say.

Imagine my delight when this came back from ESPRESSIF  – a lady by the name of Sue Chen….

Dear Sir,

Thanks for contacting Espressif Systems!

This is due to a software bug. We will fix this bug in a software release soon.

Have a great day! Thanks.

Best regards,
Sue Chen 陈思祐

ESP8266 typical pinsThis not only confirms that it IS a bug as I thought – but gives us hope that they will soon sort it out – I’ve asked ESPRESSIF to let me know when the update is available and I’ll be sure to put the info in here (make sure you follow my blog – there’s a “follow my tech blog” blue indicator on the upper right of the blog screen).

In the early hours of this morning, I received another email from them asking for debug info – basically which version I’m using – I told them 0019000902 which is the latest though I’m not sure now if it’s the official latest number, as my version has the AT+XRST command which was added by a third party (detained in this or previous blog items)… which WORKS but really you don’t want to be resetting the unit as it takes too long and happens too often.

tmpC37ESPRESSIF confirmed that the issue is incomplete commands – I suggested that such commands should be quickly timed out… you might even be sending data with AT+CIPSEND=ID,value,data and if it’s a mobile device sending this, it could fail at ANY point… the ESP8266 needs to recover from this rapidly and move on without losing the current mode – this should be simple enough – if I were designing this I’d simply time out commands. So let’s say you are talking to the board at 115k baud, that’s 10k characters a second – let’s say 1k characters a second to be charitable… so if there is a gap of say 1ms or more mid-command, or an unexpected character then the unit should simply wind back and start looking for AT….  I believe this would solve the problem…

I’m getting excited already…I could be using these boards in so many projects…  #ESP8266  #ESPRESSIF #ESP-01

Further back on this blog you’ll see other items on the subject of the ESP8266 as I fumbled my way along with very little info. There is also some technical blogging regarding Arduino and similar on my home blog

There is some code for the ESP8266 on this blog for the Teensy 3.1 …


19 thoughts on “ESP8266 Woes… a Ray of Light

  1. Thanks for good information !

    I have manged to update it with esp8266_flasher.exe with latest firmware from

    But I’m failing to update when the firmware is split int two parts ( built with sdk ), can I still use esp8266_flasher.exe or should I use “esptool”+python ? ( any suggestions ? )

    Do you know if esp8266 could be used as repeter ? ( would be extremely useful )


  2. Will do and please believe your efforts are WELL appreciated but I’m now stuck in a hotel in the middle of England for a series of non-stop Federation of Small Businesses (FSB) meetings and won’t be back at my workshop until Friday night at which point I’ll be testing this.



      • Can’t view as in meeting – will look tonight – this is just the kind of info people need – some of the assumptions out there that only those familiar with Linux will be doing this stuff, don’t help. Magic, will respond later. I really would like to be able to get in there and modify code – get rid of the Chinese-ish messages and make the responses more consistent (I think all commands should elicit a 1 line or 2 line response with the last line always saying OK or ERROR).

  3. I just took a look (sadly in hotel right now – not back until Friday night) – not seen the latter program before but it does look like you have managed to compile and blow a version- I did not a clock skew message but I guess it must be working. I’m looking forward to the weekend and tackling this one… So I’m assuming we can ignore the source code version of the ESP test tool – one of those zip files has an EXE version that looks just like your demo for blowing the WIFI chip… I’m not sure where I went wrong with the compiler – I have the same VM setup as you by the look of it.. well, I’ll find out at the weekend – the instant I can actually compile and blow working code I can start experimenting with how to turn this little board into a winner – unless you beat me to it but I’ve not yet managed to narrow down EXACTLY how to get the board into the “busy s” stuck mode.. manually sending incomplete commands doesn’t seem to do it but as soon as I run an Android program to constantly poll the unit (which works fine for hours on end) then close the program and start it again – bang, the board ends up busy needing a reset.

    I’ve been thinking about the radio network I’m using and wondering if indeed that is even necessary if this board does the job – one could simply have stand-along boards and a phone app where each page of the app talks to a specific board… I’m sure having them talk to each other by simple sockets should be easy enough. So many possibilities.

    • The “clock skew” message is a warning. The system time is not updated I guess.

      You can use whatever tool to updload the firmware. The one in the video uploads all the bin files in their respective memory locations at the same time. ( I don’t know how to make one bin file with all of them embedded)

      If you download and unzip the SDK and AT inside the virtual machine, the file permissions is not set correctly and and other python scripts will not run, however if you do it mouting the filesystem the permissions are ok and everything works.

      I have been watching the source code from AT and it is relatively simple to do modifications. The defined AT commands and its respective functions are in users/at_cmd.h. The users/at_WifiCmd.c has the code to AT+CW commands, the users/at_ipCmd.h has the code to AT+CIP commands, the users/at_baseCmd.c has the code to general commands like AT+RST or AT+GMR. The responses are always done by calling the uart0_sendStr function.

      The busy situations I achieved are when I write commands while another command has not yet sent the answer (Like executing AT+CIFSR while a previous AT+CWJAP is executing). Try the last firmware compiled by you and see if the busy error happens again.

      I think a radio network is possible. The IoT example than comes with SDK could be a good start point to do that.

  4. Might not be a bad idea Oscar to be specific about how you got that compile environment up and where the code came from – I followed one lot of instructions and the code output was simply not right..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s