There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.
Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.
Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.
There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.
One of the disadvantages of having cheap WiFi-capable boards like those based on the ESP32 is that you have to update them. If you have even a few in every room of your house, it can be a pain to pull them out and connect them to a cable for programming. Over the air programming is a great answer, and [Kevin] shows how you can control the update via a simple GUI. You can see a video demonstration of how it works below.
[Kevin] uses a ready-made OTA library to do the work, but creates a GUI configuration and downloader tool. There is a manual step to force the board into the OTA mode, which might be a mild inconvenience, but it improves security since you need physical access to the device to do an update.
Potentially, one of the great things about having a device connected to the network is that you can update it remotely. However, how do you make that happen? If you use the Arduino setup for the ESP8266 or ESP32, you might try [scottchiefbaker’s] library which promises to make the process easy.
Adding it looks to be simple. You’ll need an include, of course. If you don’t mind using port 8080 and the path /webota, you only need to call handle_webota() from your main loop. If you want to change the defaults, you’ll need to add an extra call in your setup. You also need to set up a few global variables to specify your network parameters.
A few months back we first brought word of the progress being made in unlocking the SMART Response XE, an ATmega128RFA powered handheld computer that allowed teachers to create an interactive curriculum in the days before all the kids got Chromebooks. Featuring 2.4 Ghz wireless communication, a 384×160 LCD, and a full QWERTY keyboard, schools paid around $100 each for them 2010. Now selling for as little as $5 on eBay, these Arduino-compatible devices only need a little coaxing and an external programmer to get your own code running.
The previous post inspired [Larry Bank] to try his hand at hacking the SMART Response XE, and so far he’s made some very impressive progress. Not only has he come up with his own support library, but he’s also created a way to upload Arduino code to the devices through their integrated 802.15.4 radio. With his setup, you no longer need to open the SMART Response XE and attach a programmer, making it much easier to test and deploy software.
[Larry] has written up a very detailed account of his development process, and goes through the trouble of including his ideas that didn’t work. Getting reliable communication between two of these classroom gadgets proved a bit tricky, and it took a bit of circling around until he hit on a protocol that worked.
The trick is that you need to use one SMART Response XE attached to your computer as a “hub” to upload code to other XEs. But given how cheap they are this isn’t that big of a deal, especially considering the boost in productivity it will net you. [Larry] added a 5 x 2 female header to his “hub” XE so he could close the device back up, and also added a physical power switch. In the video after the break, you can see a demonstration of the setup sending a simple program to a nearby XE.
An Arduino and a data radio can make a great remote sensor node. Often in such situations, the hardware ends up installed somewhere hard to get to – be it in a light fitting, behind a wall, or secreted somewhere outdoors. Not places that you’d want to squeeze a cable repeatedly into while debugging.
Using the NRF24L01 chip with the Arduino is a popular choice to add wireless communications to a small project. By installing one of these radios on both the remote hardware and a local Arduino connected to the programming computer, it’s possible to remotely flash the Arduino without any physical contact whatsoever using Optiboot.
The writeup is comprehensive and covers both the required hardware setup for both ends of the operation as well as how to install the relevant bootloaders. If you’re already using the NRF24L01 in your projects, this could be the ideal solution to your programming woes. Perhaps you’re using a different platform though – like an Arduino on WiFi? Don’t worry – you can do OTA updates that way, too.
[mirko]’s motivation is simple enough – a desire for IoT devices that don’t need to phone home to the corporate mothership, combined with wanting to avoid the labor of cracking open every Sonoff device to reflash it with wires like a Neanderthal. The first step involved connecting the Sonoff device to WiFi and capturing the traffic. This quickly turned up an SSL connection to a remote URL. This was easily intercepted as the device doesn’t do any certificate validation – but a lack of security is sadly never a surprise on the Internet of Things.
After capturing the network traffic, [mirko] set about piecing together the protocol used to execute the OTA updates. After a basic handshake between client and server, the server can ask the client to take various actions – such as downloading an updated firmware image. After determining the messaging format, [mirko] sought to create a webserver in Python to replicate this behaviour.
There are some pitfalls – firmware images need to be formatted slightly differently for OTA updates versus the usual serial upload method, as this process leaves the stock bootloader intact. There’s also the split-partition flash storage system to deal with, which [mirko] is still working on.
Nevertheless, it’s great to see hackers doing what they do best – taking control over hardware and software to serve their own purposes. To learn more, why not check out how to flash your Sonoff devices over serial? They’re just an ESP8266 inside, after all.