It’s been a hard couple of days, but I’ve finally managed to get OTA (over-the-air) firmware updates working on an ESP8266 running MicroPython.
Building and flashing OTA firmware
This assumes you have a working ESP toolchain (maybe see this comment if you don’t yet), and have been able to build and flash custom micropython firmware.
The bootloader/OTA software is available at yaota, but the instructions for how to actually build and flash the initial OTA server and regular app are not complete. Here’s what I ended up having to do to get it to work.
- Before you build, you need to generate keys:
$ cd ota-client $ . gen_keys.sh $ python -c "import rsa_sign; rsa_sign.dump_c(rsa_sign.load_key())"
The last step outputs some data from the key - specifically you need the
modvalue, and this needs to be used in a
config.hfile at the root of the project. Duplicate the config.h.example file, and replace the
MODULUSvalue with your public key’s modulus.
I needed to make some other changes too: until they are merged, you can see them here. They are seperate pull requests, because whilst they all need to be applied to get a build to complete, they are all independent.
Once these patches have been applied, run
makeat the root of the project.
Flash the generated
yaota8266.binfile to location
0x0of your device.
Flash the micropython OTA build to location
0x3c000of your device.
You should now be able to apply OTA updates. I also included in my
ota-server the patch from ulno that allows for triggering OTA from within micropython code. I added into my micropython firmware a file
ota.py, that contains:
import machine def start(): machine.RTC().memory('yaotaota') machine.reset()
This means I can trigger an OTA state by doing:
import ota ota.start()
Performing an OTA update.
In order to do this, you must have built and flashed your own
yaota8266, with your own keys. Otherwise you won’t be able to sign the updates, and the ota-server binary will reject them.
Trigger an OTA state (either using the process above, or by hitting a button in the 3 seconds after the bootloader is complete).
Then, in the
ota-client directory, execute the following:
$ ota_client.py live-ota <../../micropython/ports/esp8266/build/firmware-ota.bin> -a <10.9.8.160>
This will send off the 2274-ish packets to the device, and after this you should have your new firmware installed. Note you’ll need to supply your firmware file and IP address.
Notes that I came across during this process.
- If you are able to flash both images correctly, but get errors from the micropython app, check that you aren’t flashing a non-ota build. In my case, the boot sequence was performing as expected, but when no OTA state was detected, and the micropython app was due to start, it was crashing with an error:
Fatal exception (0): epc1=0x4020a8ac, epc2=0x00000000, e...
I was unable to get an OTA update to work on my ESP8266-01 device. This could be because it doesn’t have enough flash, or some other reason.
The sonoff device(s) I have require flashing using
-fm doutmode: with other modes a
write_flashwill appear to succeed, but the binary will not be viable, and only garbage will be seen on the screen.
Some USB-serial converters do not provide enough current to power an ESP8266 running in anything other than flash-from-UART mode. That is, you will be able to flash them, but not boot into regular apps.
Having a USB-serial converter that has RTS/DTR means you can have
esptool.pyautomatically trigger boot mode. This is nice. It’s a shame that the sonoff devices don’t expose enough pins to hook this up though.
As an aside, my micropython builds contain the
mqtt client library, and automatically set up the WiFi credentials for the network they are installed in. ESP8266 devices retain their WiFi credentials and attempt to restore their connection state after restart, so that can simplify code somewhat, and you can just edit the configuration in the
Now, I just need to come up with some mechanism for triggering the OTA state in a device using MQTT, and for devices that are not continually awake (I have several sensors that use deep-sleep for some time, and then wake up, publish an MQTT message and then go back to sleep).