The software development process for an embedded device is not a one-time action. Even if you have managed to make your code “bug-free”, there are always improvements or new features to add along the way. Look, for example, at Tesla, a car manufacturer that continuously provides new fixes and features to the cars in the field.
Before firmware over the air (FOTA) updates became common for electronic devices, users had to deal with updates manually. Fifteen years ago, a common approach to changing firmware for your mp3 player was to connect the device to a PC via USB cable and download a special utility and new binary from the manufacturer WEBsite and flash firmware manually. If the update process was interrupted by power loss, for example, one could end up with a hardware brick that would never play music again.
Nowadays, over-the-air updates provide a secure and reliable way to stay updated with the latest features.
For smart home devices, FOTA updates are usually done either using Bluetooth low energy (BLE) or WiFi technology. BLE-capable devices usually have a corresponding mobile app feature that notifies you when new firmware is available for download. On the other hand, devices with WiFi support can also offer firmware updates using a WEB interface. Such an approach from the user perspective is usually similar; the only difference is that you use a WEB server rather than a mobile app.
Here at Lemberg, we suggest customers always consider adding FOTA functionality to IoT devices. This article highlights how we do FOTA updates in real Wifi-enabled microcontroller-based products.
FOTA implementation approaches
Depending on the WiFi module, the following types of FOTA are commonly used:
- native FOTA feature built-in WiFi module;
- custom FOTA implementation.
For devices which application code is hosted solely on a WiFi module, the first option is the best as it avoids custom FOTA implementation. However, when a device consists of a host microcontroller unit (MCU), which runs the application code, and a WiFi module for connectivity support, a custom implementation must be considered.
FOTA workflow
FOTA update workflow is illustrated below.
New firmware download
As the first step, the device downloads new firmware binary from a remote WEB server. New firmware can be downloaded from a remote server in various ways — for example, using FTP or HTTP/HTTPS protocols.
If possible, it is better to download firmware as a single file instead of in chunks. The latter allows you to avoid possible lack of RAM to store the whole file, but it requires careful reassembly of packets if the download is interrupted, for example, due to communication issues.
Persistent memory storage
After the firmware is retrieved from the server, it must first be stored in some type of persistent memory before flashing to the microcontroller’s internal memory. This is done to ensure firmware integrity, which could be impacted during downloading. Integrity is usually checked by calculating the CRC sum of the downloaded file and comparing it with CRC values appended to the firmware during compilation. External EEPROM or Flash internal MCU memories are usually used as persistent storage. Storing binary to external memory is usually preferred to avoid unintentional corruption of internal flash. However, when external memory is not available, the second option can also be considered.
Bootloader
When new firmware is downloaded and its CRС is validated, it’s time to involve the bootloader. A bootloader is a special program that usually resides inside internal MCU memory and has a task to substitute the current firmware with the new one. The bootloader can also provide much more functionality, but, for smart home devices, which do not run Linux, it is usually quite simple.
To enter the bootloader, the application code usually performs a CPU reboot followed by launching the bootloader. The bootloader can then check if new firmware exists on persistent memory and copy it to internal memory.
Flashing new firmware
Flashing new firmware is usually straightforward and just requires deleting the current firmware and copying the new one instead. However, it is very important to carefully handle all issues that may arise during programming as this can lead to broken hardware (remember the case with the mp3 player at the beginning?). For example, if the device reboots while copying, internal memory will contain truncated binary, which may not start or can work with undefined behavior.
In our implementations, we always try to foresee such issues and accompany the bootloader with additional safety features, like factory default firmware. In case of error, the bootloader can always roll back to factory binary if it can’t program or load existing firmware. When a firmware update is complete, the application code will always send an acknowledgment to the remote server to confirm that FOTA was successful or notify the user that some failure occurred.
Summary
During the development of electronic devices, you should always consider adding FOTA functionality to ensure device safety and flexibility. A firmware update option may seem redundant due to time and cost increase, but it will always pay off afterward during support and maintenance.
Check out our embedded Linux development services and how Lemberg's IoT team might contribute to your project.
