Bootloaders

The bootloader is the first application that executes within a device and it provides the ability to either update (re-program) or execute a secondary runtime application. The bootloader ultimately provides a method for performing in-field software updates.

Although most modern microcontrollers contain internal bootloaders installed by the manufacturer, they lack the interfaces and features that are typically required for consumer devices. Our software provides everything that is needed for creating bootloader applications for end-user devices. When applicable, our demos include a fully functional bootloader application. The demonstration bootloaders also provide the ability to deploy secure data images that have been encrypted using AES encryption.

Which Application To Execute?

The bootloader will be the first application that is executed upon power-on reset of the device. The bootloader is tasked with making a decision between launching the runtime application or continuing to execute itself. How the bootloader makes this decision is very important. If the bootloader incorrectly launches a bad or corrupted runtime application, the device can become inoperable (bricked). To ensure that this condition is never possible, it is best to always allow for some external method of forcing the bootloader to choose to execute itself. Below are two methods that can be used for forcing a bootloader to execute itself.

• Dedicated Pin (button)
  Have the bootloader check the state of a pin upon boot-up to force the bootloader to execute. This method works well assuming the end-user has a method for accessing this pin/button. This is the typical method used for built-in bootloaders that are provided by the chip manufacturer.
• Timeout Period
  Have the bootloader wait some amount of time before launching the runtime application which gives the end-user, or controlling software, a method to interrupt the bootloader and command it to execute itself.

The bootloader can always perform an additional validation check of the runtime application before launching it. This validation can range from being as simple as checking if the memory is blank, to performing a CRC calculation upon the entire runtime image. It is important to understand that having validation of the runtime application does not remove the need for an external method of forcing the bootloader to execute. Validation, such as a CRC, only verifies that the application has been programmed correctly, and provides no guarantee that the application will not crash or halt every time it is executed.

Execute Bootloader From Runtime

It can be convenient to have a method for requesting the bootloader application to execute while already executing the runtime application. Having this feature provides an end-user with a seamless, automatic process for programming the device with a new runtime application. Our demo bootloader applications provide this functionality by using a special value stored within a specific location of RAM. The location is agreed upon by both the bootloader and runtime application and serves as a space to communicate between the applications. When the bootloader is launched, it checks this RAM location for a specific value, and if it matches a specific value, it will skip launching the runtime application and execute itself. These parameters can be adjusted within the boot_cfg.h header file. The RAM location that is used is defined by CFG_BOOTSIGADDRESS. The specific value that causes the bootloader to execute itself is defined by CFG_BOOTSIGNATURE. If either of these settings are changed, both the bootloader and runtime applications have to be updated (recompiled) in order for the feature to work correctly.

Security

Our bootloaders provide the ability to enable the use of AES encrypted data files (firmware images). There are several benefits to using encrypted data files with a bootloader. First, it protects the image files from be disassembled. This may be important if your software contains intellectual property that can be reverse engineered by your competition. Second, it keeps anyone else from being able to load different software into your MCU. Without encryption, someone could potentially write their own software for your device and they would be able to use your bootloader (or even the on-chip bootloader provided by the MCU manufacturer) to load their program onto your hardware.

Supported Bootloaders

• USB Device Firmware Update (DFU)