Over-the-air (OTA) updates can future-proof wireless designs

Wireless connectivity is no longer an enhancement option. More device design specifications require wireless connectivity and many are using multi-frequency band and multiprotocol; Bluetooth, ZigBee, Thread, proprietary and Wi-Fi.  

Over-the-air (OTA) firmware updates to field devices, delivers new features or other changes after a product has been deployed. Embedded wireless MCU Systems-on-Chip (SoC) devices with on-chip, expanded 1M byte flash and SRAM enable the device to run multiple protocols and complex applications, while providing enough flash for OTA support without the need for an external serial flash. OTA functionality enhancements in the Bluetooth stack and boatloader have simplified OTA development.

This article will discuss the following:

• OTA firmware update concepts
• Types of OTA updates
• OTA applications techniques

The ability to update the firmware of Bluetooth devices already deployed in the field is a common requirement for many products. For example, it may be necessary to add new features into products after the first version has been launched. If a software bug or some unanticipated compatibility issue is identified after the product has been shipped, it is essential to provide a firmware update that fixes the problem, without the need to recall units or for the customer to take them to service for reprogramming.

Products that use Bluetooth Low Energy technology are often designed to work with smartphones, tablets, or similar consumer electronic devices which are connected to the Internet. This makes it possible to implement OTA firmware update capability without adding any extra cost or significant increase in the software complexity. The Internet of Things (IoT) also creates a challenge, because new types of devices and use cases are continually introduced, which can create unanticipated interoperability issues. OTA firmware updates are essential for any IoT device.

The OTA update process must define OTA clients, error recovery, security, and reduce overhead costs. The following table list typical requirements for OTA implementation.

OTA Firmware Update Requirements

Support for Field Upgrade

Software in a Bluetooth-enabled device can be separated into two areas:

• Protocol stack, link layer implementation, Low-level radio driver from the hardware vendor
• User application code that use the features provided by the protocol stack

There are reasons for device firmware field upgrades.  A firmware update may be needed for reasons not under the control of the application designer. For example, the Bluetooth specification is under constant development, with different revisions of the protocol stack released over time. A revision may include new features, performance optimizations, and patches to bugs or interoperability issues. It may be desirable to use the OTA update procedures to change to the latest available stack revision, even if the user application itself remains unchanged.

The user application upgrades may also be necessary for operating system or libraries to provide feature enhancements such as cryptographic functions. In other cases, the changes to be applied with OTA update are limited to the user application. Examples include fixing a security hole, or making a minor configuration change that results in improved battery lifetime. In such cases, it is desirable to update only the user application, without touching the protocol stack or other lower software layers.

Field upgrade support is provided by boatloader utility enhancements in vendor embedded Software Development Kit (SDK) revisions.  The boatloader adds features such as a configurable base framework, security options, support of multiple update images and in-field updates for the boatloader itself.

OTA Type comparison

Bluetooth SDK supports two ways of performing OTA updates:

• Full OTA: Updates both the Bluetooth stack and the user application
• Minimal OTA: Updates only the user application

Full OTA updates everything except the bootloader provides almost the same level of flexibility as when programming the device using a cable during the development phase.

Minimal OTA updates only the user application, leaving the Bluetooth stack and the other low-level firmware layers intact. The benefit of minimal OTA is the smaller size of the firmware update image, allowing a faster update procedure with lower energy consumption.

To further explain the difference between full and minimal OTA, consider the following (theoretical) example:

• The total size of the firmware image is 130 kB (stack and application)
• The stack size is 115 kB; the application size is 15 kB
• The average transfer speed when uploading the firmware image is 25 kbit/s

With these parameters, transferring the full firmware image takes (130*8)/25 = 42 seconds to complete, while the minimal OTA image can be transferred in just (15*8)/25 = 5 seconds.

In-Place OTA Technique

 In many OTA solutions the update requires a lot of free flash memory to be used as a temporary working area during the update. A simplified OTA update sequence could be summarized as follows:

• Upload a new complete firmware image into temporary storage.
• Reboot the target device into bootloader mode.
• Bootloader copies the new firmware image on top of the old image.
• Bootloader resets the device and the execution continues from the new application.

This kind of OTA procedure is simple to implement, but there is some significant overhead. Typically the amount of available flash must be doubled to make enough space for the temporary storage. The extra flash can be provided by using a SoC with very large flash memory or possibly even an external flash memory chip, which adds extra system cost.

The Silicon Labs OTA implementation eliminates the need for extra flash storage by using an in-place update. In summary, the software is divided into two parts that reside in separate areas of flash memory.  Figure 1 below illustrates how the flash memory is organized assuming a total flash size of 256 kB (top address 0x40000).  The first 16 kB of flash is reserved for the bootloader and is not touched during OTA updates.

Figure 1.  Flash Memory Segmenting

The available flash memory is split roughly in half between the stack (and bootloader) and the user application. The stack resides on the lower half of flash and user application is located on the upper half. At the end a fixed area is located for Persistent Storage (two flash sectors, 2 kB each). Note that the point where the stack area ends and the application area start is not fixed across different SDK versions. Therefore is a small gap, empty address space, between stack and application code.  The size of this free area depends on the application size.

Full OTA Sequence

The protocol stack and user application have their own memory spaces and the update is done in two phases. The flash addresses reserved for application use can be used for the temporary storage during the two-phase update. This has two benefits.

• First, it eliminates the need for extra flash for temporary storage.
• Second, it supports updates that only update the application without touching the stack.

A full OTA can be summarized in three steps as follows:

• Upload the new stack image to the application flash area.
• Copy the new stack image to the stack flash area.
• Upload the new application to the application flash area.

The following Figure 2 illustrates how the full OTA update proceeds in terms of flash memory content.

Figure 2.  Full OTA Update process

In the Figure 2, the memory content before update (a) shows the current stack and application images are located in the lower and upper half of flash, respectively. The application provides a means for the remote BLE client to boot the device into Device Firmware Upgrade (DFU) mode.  The device is in DFU mode (b), OTA functionality built into the stack allows the remote client to upload a new stack image (stack(2)) on top of the application area. After the new stack image is uploaded, (c) the device is rebooted and the bootloader copies the new stack on top of the old one. Then the device reboots into DFU mode again. At this point there is no application in the upper half of flash and the only option is to stay in DFU mode. The remote client uploads the new application (app(2)) (d) that is placed in the upper half of flash. For this reason, any application-specific data that is stored in this area is not preserved across full OTA updates. Finally, (e) shows the flash content after the full OTA update stack and application have been updated.

Silicon Labs OTA solution

The Silicon Labs EFR32BG12 Wireless System-on-a-Chip (SoC) and BGM1xx Bluetooth Modules offer field upgrade via OTA.  The EFR32BG12 with up to 1024K Flash and 256K RAM memory support unicast & multicast OTA field upgrade.  Silicon Labs is introducing larger memory Wireless SoC modules other OTA features with regulatory certification.

  Summary:

Over-The-Air (OTA) enables deployment of firmware updates to devices in the field, making it possible to introduce new features or changes to deployed products in the field.  Embedded wireless System-on-Chip (SoC) devices with expanded >1M byte flash and SRAM enable the device to run multiple protocols and complex pplications while providing enough flash for OTA support.  Wireless Sensor Networks and the Internet of Things is taking OTA in a new direction using Bluetooth/BLE, 802.15.4 and ZigBee protocols.

To learn more:

Visit RS Components:  

EFR32BG12 Bluetooth SoC (134-7228)  

EFR32MG12 ZigBee SoC (134-7234)  

BGM111 Bluetooth Module (894-7130)

MGM ZigBee Module (124-2552)