The scale of the Internet of Things (IoT) brings many challenges to deployment. In our homes alone, we’ve seen a dramatic increase in the number of connected devices from just a router and a couple of personal computers to multiple smart devices that remotely lock doors, activate window blinds, control lighting, manage temperature and humidity, and more. In order for this multitude of devices to remain relevant and secure, over-the-air (OTA) firmware upgrades must become an integral part of IoT systems.

Imagine a huge marketplace where a deployment of beacons gives information about products on display. The location of these beacons might not be easily accessible and the number of these beacons makes it impossible for them to be programmed individually post deployment. Hence, when there is a new feature or a defect that mandates re-deployment, OTA firmware upgrading becomes an important timesaving feature.

OTA firmware upgrades over BLE

The effectiveness of OTA has been proven in applications like mobile phones that receive new features and fix bugs through periodic upgrades and the relatively new OTA firmware upgrade feature with Bluetooth Low Energy (BLE) has brought this same ability to the IoT.

There are three primary reasons driving OTA firmware upgrade over BLE requirement in the context of the IoT:

Wide and heterogeneous device deployment

The number of devices, and different types of devices, play a very important role in a distributed network. A standardized OTA interface ensures reuse of the architecture across different nodes. Consider smart lighting in a stadium: while a huge floodlight and a hallway light may differ in their capabilities, a standard OTA interface over BLE can be reused across them. This means that the host device that pushes new firmware across these heterogeneous devices can be a common platform. It also means all the lights of different types in the stadium can be upgraded from a control room rather than through multiple individual upgrades.

Changing requirements and new features

The IoT is a growing and rapidly changing market with new product requirements, and new BLE features are added regularly. Security threats and privacy breaches are some of the biggest factors driving these changes. To protect against new virus attacks, device firmware can incorporate fixes and more secure algorithms through the OTA firmware upgrade process. In any IoT system, there are two parts: hardware and firmware. In SoC-based implementations, OTA firmware upgrade functionality can update not only firmware, but reconfigure on-chip hardware resources as well.

Critical time-to-market needs

IoT systems have very short design cycles, and there is a need for constant innovation and deployment of the latest features. The general development process is to over-design the hardware to sustain expanding market requirements over a longer period of time. OTA firmware upgrade enables the deployment of solutions in phases. For instance, the initial design for a thermostat system can roll out quickly with just a thermal sensor and then with updates that enable the humidity sensor later on. Note that with this approach, the hardware design is a thought-through process with future rollouts considered at the architecture phase from a hardware perspective.

However, while OTA firmware upgrades are a boon to IoT applications, there are pitfalls product teams must be aware of and avoid. The ability to upgrade firmware in the field combined with extreme time-to-market demands might lead to pressure to release firmware too quickly. For example, the race to achieve the mass deployment of the product might prompt marketing to rely on the fact that firmware can be updated later. This in turn could lead to the release of unstable software or products that have not yet been fully validated or optimized. In addition, frequent updates may not be well received by end users. Product teams should carefully weigh the impact of such decisions and apply restraint to not overuse OTA.

OTA fundamentals

When it comes to fundamentals, OTA firmware upgrading is no different than any other bootloader, such as a UART bootloader or a USB bootloader. Figure 1 shows the basic architecture of an upgradable firmware-based system.

[Figure 1 | Architecture of UART bootloader system]

As the figure shows, the target device’s non-volatile memory is divided in two sections – bootloader and bootloadable. Bootloader is the section of memory that stores the code that is responsible for the device’s boot operation; checks if the host has an updated firmware image for the bootloadable section; receives the updated firmware image from the host over an UART interface; and writes the updated image to the bootloadable section of memory. The bootloadable section of memory is the actual application code that defines the system’s functionality.

Similarly, to understand OTA firmware upgrades, memory can be divided into bootloader and bootloadable sections. The primary difference here is that the communication interface is used to receive the new firmware image from the host. In case of OTA firmware upgrades, a wireless communication interface, such as WiFi, ZigBee, Bluetooth, etc, is used to receive updated firmware images over the air. Irrespective of the interface, the process and fundamentals are the same.

Today, BLE is ubiquitous as it offers lower power consumption and is supported in most PCs and mobile phones. Such widespread availability makes it a preferred choice for IoT applications. Having said this, BLE is an evolving standard; a new version is released almost every year to incorporate more features to address the evolving requirements of IoT applications.

In this competitive market, silicon vendors are in a race to offer a solution compliant to the new version of the specification. In most cases, silicon vendors support these features in stages over several BLE stack/IDE versions. Also, changing specifications leaves minimal time for extensive testing between releases, so it is common for every new BLE stack release from silicon vendors to have defect fixes that are reported by customers or captured in-house during testing or development. Thus, when BLE is used to keep an IoT device up to date, application code may require an upgrade, but the core BLE stack might need to be updated as well. A robust bootloader architecture should be able to support these different use cases and be flexible enough to adapt to changing application requirements.

OTA bootloader architectures

The IoT space is diverse, and so are the application and end solution requirements. To remain flexible, product teams should choose an OTA bootloader architecture that meets their application’s needs.

There are two types of OTA bootloader architectures available for BLE-based devices:

Fixed stack OTA bootloader

In a fixed stack OTA bootloader implementation, the stack does not get upgraded – only application-specific firmware can be upgraded. With such an implementation, the stack is stored in the write protected/bootloader section of memory. Figure 2 shows a typical fixed stack OTA bootloader implementation.

[Figure 2 | BLE based fixed-stack OTA bootloader]

A fixed stack OTA bootloader has the advantage that it takes less time to upgrade the firmware since only application-specific code can be upgraded. On the other hand, the disadvantage is the stack code cannot be upgraded even if a critical bug is discovered after deployment.

Upgradable stack OTA bootloader

In upgradable stack bootloader implementation, both stack and application firmware can be upgraded. Though the actual implementation of the bootloader may vary from vendor to vendor, in a typical upgradable stack implementation, memory is divided in three sections:

Launcher: The launcher is basically a bootloader without a communications interface. It checks if bootloading is needed and passes control accordingly either to the stack or application section. It is also responsible for upgrading the section of the memory that stores the stack if a new image is available.

Stack: This section stores the BLE stack. The stack section is responsible for talking to the host device when it has a new firmware image. Also, this section is shared with the application for BLE connectivity. Effectively, this section acts like a bootloader as well as a bootloadable. This section is bootloaded by the launcher by writing new stack firmware to this section. This section then bootloads the application section.

Application: This section is actual application code like any other implementations mentioned above.

The operation of an upgradable stack OTA bootloader can be understood in three steps:

Step 1: Figure 3 shows the target device (i.e., the device that needs to be upgraded over the air) and the host device (i.e., device that has new firmware and is responsible for sending it to the target device). The target receives the new BLE protocol stack using its existing BLE protocol stack. This new BLE protocol stack is stored in the application-specific firmware section of the memory. The application-specific firmware section is overwritten with the new BLE protocol stack because IoT devices typically have limited memory. Extra memory adds to the device cost and cannot be justified just for bootloading purposes. Note that the existing BLE protocol stack cannot be overwritten directly as this will corrupt the existing stack code that is currently talking to the host, consequently disrupting communications before the upgrade is complete.

[Figure 3 | Step 1: Existing stack receives new stack from host and writes to application-specific memory]

Step 2: The launcher copies the new BLE protocol stack from the application-specific firmware section and writes it to BLE protocol section (see Figure 4). By the end of this step, the BLE protocol section has the new BLE protocol stack.

[Figure 4 | Step 2: Launcher overwrites the existing stack with the new stack]

Step 3: The target device uses the new BLE protocol stack to receive new application-specific firmware from the host device and writes it to application-specific firmware memory (see Figure 5).

[Figure 5 | Step 3: New stack is receiving new application-specific firmware and writing to application-specific section]

After this step, the target device firmware is configured as shown in Figure 6 with both stack and application-specific firmware upgrades completed.

[Figure 6 | Memory has new BLE stack and application-specific firmware after upgrade is complete]

A key advantage of an upgradable stack bootloader is that it allows for both stack and application upgrades after the product is deployed.

Memory-based OTA bootloader classifications

OTA bootloaders can also be classified based on the memory that they use to store updated firmware images:

Internal memory OTA bootloader

With this type of bootloader, the updated firmware image – either a new BLE stack and application-specific firmware or just the new application-specific firmware – are directly written to the internal Flash of the device. The bootloader architecture structures discussed up to this point in the article have been based on using internal memory. The advantage of this type of bootloader is that external memory is not needed and so the effective cost of implementing upgrading functionality is reduced.

External memory OTA bootloader

With an external memory OTA bootloader, the existing stack receives either new application-specific firmware or new stack firmware and application-specific firmware. These are stored in an external memory. At a later time, the device reads the new firmware from the external memory using a wired interface based on the type of memory (could be I2C or SPI or any other serial memory) and then upgrades the internal Flash. This implementation increases total system cost for the external memory. It is used when a device has limited internal memory and requires its stack to be upgraded. Note that for some application use cases, stack size can be greater than the size of the application-specific firmware.

Conclusion

It is important to look into the OTA firmware upgrade methods supported by the silicon and development tools when selecting components for an IoT application. When a device with internal Flash is being evaluated, an internal memory-based OTA upgrade offers an economical approach. Some devices may not allow stack upgrades, just application-specific firmware upgrades. Some upgradable stack OTA bootloader implementations may allow just stack and application-specific firmware to be upgraded independently to reduce upgrade time. It is important to understand these constraints upfront when selecting a device for your application.

While upgrading device firmware over the air, data is transmitted over the air and is susceptible to being hacked. Thus, it is important to authenticate and make sure that the host device is talking only to the intended target device. Date that is being sent over the air should also be encrypted so that other devices listening to the BLE communication are not able to decode the data. BLE 4.2 has improved security mechanisms that provide increased protection against man-in-the-middle attacks and passive eavesdropping to reduce the treat of IP theft and takeover of a device by a hacker. If an older version of BLE is being used, it is wise to add an encryption layer manually to protect your IP from passive eavesdroppers.

IoT marketplace product requirements are changing faster than requirements for traditional products. In addition, the widely adopted BLE communications interface standard is still evolving, and it takes significant time for silicon vendors to support new features. There is also the pressure to get to market faster, potentially impacting testing time and field trials of the product. For these reasons, over-the-air firmware upgrades can add significant value to IoT products by allowing developers to enhance product functionality over time and rollout defect fixes after the product is deployed.

Richa Dham is a Senior Marketing and Applications Manager with Cypress Semiconductor. Her interests lie in defining new solutions especially in the connectivity and IoT area. She completed her Masters in Technology in Communications Engineering from Indian Institute of Technology, Delhi.

Sachin Gupta is a Staff Engineer Product Marketing with Cypress Semiconductor. He holds a diploma in Electronics and Communications from Vaish Technical Institute and a Bachelors in Electronics and Communications from Guru Gobind Singh Indarprastha University, Delhi. He has 8-years of experience in SoC applications.