The ability to update an embedded system using a bootloader is an important skill to master. Despite all the effort placed into developing an embedded system, either bugs are discovered in the field or end users request additional features. In order to update firmware in the field or remotely over-the-air, the embedded system must have a bootloader onboard. For embedded systems being updated over-the-air as part of the IoT, there are five key challenges facing development teams.

Challenge #1 – Code Size

Microcontroller based applications used to be very small, on the order of eight to sixteen kilobytes at most. Modern microcontrollers can have upwards of 1024 kilobytes worth of application code space available to developers. Despite this explosion in capacity and capability, code size poises the first challenge to embedded programmers looking to update their firmware over-the-air.

One of the challenges with code size is that microcontrollers typically don’t have onboard file systems for the application code that is being ran, unlike CPU based systems running Linux. Since files don’t exist, object files are placed contiguously within memory by the linker. A minor adjustment to the application could result in updating the entire flash space! To prevent such a catastrophe, developers need to have the forethought to partition memory with the anticipation of what areas of the code base may need to be modified. The result can be inefficient use of onboard flash and considerable complexity added the system.

Challenge #2 – Bandwidth

In general, when a developer is considering bandwidth in relation to a bootloader, the bandwidth is used to determine the maximum flash time required to update an application. Updating an embedded system over-the-air potentially adds a couple of additional challenges.

The first challenge concerns bootloaders that are required to work over a wireless link that may have a cost associated with transmitting and receiving data. In many cases over-the-air updates would probably be performed over WIFI or Ethernet but what about mobile devices that use cellular data links? Considering a single embedded system, one might dismiss the single megabyte of application code required to update the system; However, what happens when there are millions of devices that need to be updated? Considerable costs could be incurred simply to push out a single update.

Engineers developing a bootloader, especially one that is performing updates over-the-air, need to find ways to compress the application image in order to minimize the amount of data transmitted over-the-air. Compression could be performed in a number of ways or if a developer has partitioned flash space on a per object bases, the use of a diff file might even be possible.

Challenge #3 – Robustness

One of the bootloader temptations facing many development teams is to use the bootloader solutions that are provided by the chip manufacturer. The problem with chip manufacturer solutions is that they often reside within ROM space where they cannot be customized. More importantly, the ROM based bootloader is usually nothing more than functional code. Functional code can perform a purpose under controlled conditions but isn’t meant for a production environment where anything goes.

Robustness needs to be built into a bootloader solution from the beginning. A bootloader should have capabilities to verify the integrity of the onboard application. A bootloader should be able to detect a failed firmware update and roll-back to the original application rather than bricking the system. In a production environment there are many events that could upset the system but a properly designed bootloader will be robust enough to handle them smoothly without the end user ever being aware that there is a problem.

Challenge #4 – Security

Many microcontroller-based bootloaders ignore security which is a critical challenge facing developers performing over-the-air updates. One of the simplest security measures that a developer can take is to simply lock the flash system. Developers who are performing over-the-air updates might consider encrypting their application image to prevent anyone from gaining insights into proprietary firmware or even reverse engineering and hacking the system. An over-the-air bootloader should have built-in methods to authenticate the update process.

Challenge #5 – Version Management

The final challenge in this discussion facing developers of over-the-air bootloaders is version management. Managing the version of firmware that will be distributed to potentially millions of devices is no small task. Odds are, firmware updates won’t be pushed all at once but instead in controlled batches. Even more importantly, chances are that different versions of hardware will exist at some point and potentially even different application sets for different end-users. Keeping track and making sure that firmware roll-outs go smoothly can be a major challenge.

Conclusion

Bootloaders are usually ignored up until the end of the development cycle, yet they play a critical role in an embedded system. The five challenges presented here are just a few that are facing embedded software developers who are developing connected systems using microcontrollers.