The Internet, for many years now, has provided a unique medium from which embedded systems developers can update their embedded firmware. Prior to the Internet, a technician had to get physical access to the device so that he or she could access the bootloader and update the firmware. Today, no matter where in the world the device is located, it can call home and ask for the latest-and-greatest firmware with bug fixes and feature updates.
Here are five tips that should be considered when designing how an embedded system will be remotely updated:
1. Download the Entire Image First
There are many techniques that can be used to update an embedded system’s firmware. One of the lowest-risk ways is to wait for the entire firmware image to be received locally prior to writing it to Flash. Waiting for the entire firmware image has a number of advantages. First, if the Internet were to temporarily go out or if the embedded system lost access to the Internet, the update procedure wouldn’t have to be aborted and the system wouldn’t be left in an unknown state. Second, receiving the entire image allows it to be validated prior to the start of writing the image. A failed checksum or suspicious string sequence could be identified as a fault and the firmware would not be updated.
2. Build-in Multiple Application Images
Sometimes, developers get lucky and have a plethora of Flash onboard the microcontroller. Extra Flash space opens up the possibility of breaking up the Flash space into multiple application spaces. For example, it might be possible to have a factory firmware image location, an update application slot 1 location, and an update application image slot 2 location. New firmware updates would first be stored in application slot 1 and then application slot 2. Each subsequent update would then bounce between the two. In the event that an image update fails, the embedded system can then continue to run the previous image. What happens if both application slots fail? The original firmware is still onboard, hopefully in secure Flash with the bootloader, and can be used as a worst-case-scenario fallback.
3. Consider Using a Delta Generator
Transmitting an entire firmware image to an Internet-connected device over a cellular network could quickly become costly. In order to prevent large charges or even excessive uses of bandwidth on a standard network, a delta generator can be used. A delta generator basically looks at the Flash image that is currently in use and determines how it changed. Only the changes are sent to the bootloader for updating. In a file-system-based embedded system, this is a trivial exercise, but in a low-cost microcontroller environment, it can be a little more challenging. For example, modules or blocks of code may need to be manually located in order to provide additional Flash space so that the module can grow without causing the delta generation to become excessive.
4. Encrypt the Image
Security has nearly as much buzz around it as the IoT -- and for good reason. Devices that are connected to the Internet need to be secure. There are a number of ways that this can be done, but a good first step is to encrypt the firmware update image. Encryption makes it more difficult for hackers to gain access to the firmware and consequently insights into how the system works.
5. Verify Situation Status
Before a firmware update is ever performed remotely, the status of the system should be verified. For example, what if the particular system is battery operated and the battery is low? Starting an update procedure during low battery could cause the system to reset when Flash is written or, worse, the system could go dead during the update. What would the end state of the firmware be then? Another situation to check is if the device is currently in use. People loathe the way a device suddenly starts to perform an update when they are in the middle of doing something. The embedded system should check and verify that it is in a good state, with sufficient time to safely and correctly perform an update.
Updating an embedded system over the Internet is becoming a common practice. There are many techniques and models that can be used to do this safely and robustly. The five tips here are just the tip of the iceberg. An additional resource that might be of interest is a free white paper entitled “Boot-loader Design Techniques for MCU’s.”
MORE FROM DESIGN NEWS: Challenges for Embedded Technology Designers in the IoT
MORE FROM DESIGN NEWS: Famed Hacker: IoT Is Exploitable
Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at email@example.com, at his website www.beningo.com, and sign up for his monthly Embedded Bytes Newsletter here.