As the blog entry on using my home control code ROMS for ESP8266 is filling up and of course as much of the information is now dating I thought I’d do a new blog to bring everyone up to speed and move the conversation to this blog entry. The good news is – the code is now running under SDK 2.0 – i.e. bang up to date at the time of writing.
Firstly – yes, everything works – but the procedure for blowing ROMS has changed ever so slightly. I have updated the binary files to run on SDK 2.0 and updated the RBOOT code I use for OTA (over-the-air updating) to the latest version.
To backtrack a little…
I’ve written software for the ESP8266 which has been in operation for some time and is under constant development. It allows the ESP8266 to control things like simple lights, serial LEDs, PWM LEDs and read sensors etc, talking via WIFI and MQTT to whatever central system you have – for example a Raspberry Pi with Node-Red. I’ve written a node to allow endless units to log in and to provide central communications for them. The software is rock solid and runs 24-7.
I use Windows to develop the software using the Cherts unofficial development environment. This provides an IDE using Eclipse for running and compiling C code. It is not necessary to use any of this if you simply FLASH the ROMS which are available – but of course if you do use the IDE you can customise code for your own use. The projects Home Control 2016 and Nextion WiFi Touch Display both use the same software and are the end result of many years developing home control. Personally I access much of this equipment using Apps like Blynk and more recently Imperihome (see also this article, this and this). Tools I use in Node-Red include my own BigTimer node. All of these options were chosen after much deliberation.
So what have I learned and what has changed?
All has been going well until recently when the Espressif SDK for ESP8266 was updated, firstly to 1.54 then very quickly followed by 2.0 and all of a sudden I and other started to have issues starting up ESP8266 boards. This is now resolved incidentally.
Firstly one of my problems was lack of serial output on power-on. Some serial (115Kb) status messages I have on power up, just point-blank refused to show. I figured the code might be starting at the wrong place. But no, a quick port flick at power-up proved that everything was working – but no serial out.
After much debugging, I discovered that there would be no serial output until this function:
had been called. Prior to SDK 1.54 this was NOT the case. Simple enough I put this at the start of my code – I need to ensure that web updating still works but merely moving this function to the start solved all the serial output issues.
The second problem was a tendency for the unit to run away, firing out garbage as if the ESP-12 was broken. It would SEEM that post-SDK-1.53 – it is necessary on initial run, to flash location starting 0x3fc000 with the default file esp_init_data_default.bin which is found in the Espressif development kit. If this has already been blown (previous installation) then it is not necessary but with a CLEAN FLASH, failure to flash this area results in the continuous rubbish on output. Again this was not the case before SDK 1.54 – I have NEVER flashed that location in the past. Once blown it is not necessary to blow this again for OTA. Still – once warned….
There are 2 relevant files. A file called blank.bin sits at 0x3fe000 (top of the third MB in a 4MB Flash i.e. ESP-12) and contains default system parameters produced in the SDK. NOT setting this initially seems to have no effect on my code.
A file called esp_init_data_default.bin sits at 3fc000 and contains default system parameters stored in the SDK. This is a 1K file. This HAS to be blown when first setting up a chip.
What to do
There is a binary file called esp_init_data_default.bin which I have added to the server at www.scargill.net – this is in addition to rboot.bin and romx.bin
In the Espressif setup there is a file called ESPTOOL – there are exe versions and .py versions of this floating around. This is what I use to flash the ESP8266 chips – there are others – you may use them – but I can’t VOUCH for them!
In Windows this works for me – you will have to check for yourself.
To completely wipe an ESP12 – including all data and setup etc and assuming COM3 in this case.
esptool.exe -p COM3 -b 115200 erase_flash
To initially flash the code… assuming you have the 3 files mentioned above…
esptool.exe -p $(COM3) -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 rboot.bin 0x02000 romx.bin 0x3FC000 esp_init_data_default.bin
Obviously you can change port, speed and file locations. I usually double up on that baud rate but this one is safe.
I’ve tried NODEMCU FIRMARE PROGRAMMER and that seems to work (but this does not totally wipe everything including user data etc.
And so there it is – the source is updated on the web and requires SDK 2.0 or better to run. The ROMS are updated and the new file is up there.
Why worry about updates indeed? Well, one good reason – is that recently, updates to the SDK have used LESS precious RAM – the kind that programs (not data) run in – so with 2.0 there is more margin for expansion – which means more features and more room for more features!
A complete and utter aside
I don’t use the Arduino setup but as I was thinking about user data, I just checked the Arduino EEPROM library SOURCE for ESP8266 and it would appear that does NOT use this 3-sector trick. When you update the EEPROM (which is actually FLASH on the ESP8266), the sector is wiped (even if you have user data smaller than 4k, a 4k sector is still used) and then updated from RAM – not ideal. I don’t know if that is the case in the actual ESP8266 Arduino environment as I can’t seem to find the actual EEPROM source!