Introduction and Requirements#
NOTE: This section replaces AN1384: Over-the-Air Bootload Server and Client Setup for Zigbee SDK 7.0 and Higher. Further updates to this application note will be provided here.
Updating devices over the air (OTA) is mission-critical, as it enables the addition of new features, resolution of bugs, and patching of security vulnerabilities without physical access to the device. Zigbee supports this capability through the Zigbee Cluster Library (ZCL) OTA update mechanism. This allows firmware updates to be transferred to any Zigbee device on the network that also support OTA. Typically, the Zigbee coordinator acts as the OTA server, while other devices on the network function as OTA clients. The server transmits the firmware image to the clients.
The complete OTA firmware upgrade process can be broken down into the following steps:
Develop and compile the updated firmware image.
Load the new device firmware onto the OTA server, usually the coordinator.
Zigbee devices will periodically poll the OTA server for new firmware.
When new firmware is found, the new image is transferred to the client block-by-block until the complete image is transferred.
Once fully downloaded, the image will be checked for validity.
After a successful validity check, the device will reboot into the bootloader.
The bootloader will copy the received image to the correct flash location to overwrite the old image with the new image.
Refer to Bootloading Fundamentals for more details about the bootloader. For details about the ZCL OTA Upgrade cluster, consult the latest published revision of the Zigbee cluster library specification.
Server Requirements#
The server is the device that transports the image to the other devices on the Zigbee network. In the most common use case, the OTA server is the coordinator, which can have different architecture styles. The architecture influences how the OTA image is stored: hard disk or external flash.
In most cases, a Linux system connected to a development board acting as a UART NCP or RCP is the friendliest option for an OTA server because there are many mechanisms to push the OTA file into the server’s file system.
It is possible for an OTA server to run on an EFR32MG-based SoC, or to use an NCP with a different (non-POSIX-based) host system. These configurations require an alternative mechanism for pushing images into the OTA server so they can then be served up to clients through the Zigbee OTA bootload cluster protocol. For example, software images could be pushed through a utility backhaul, an Ethernet connection to a local network, or some other proprietary mechanisms.
The following figure depicts the most common architectures and their storage modes.
For more information about the different architectures, refer to Software Design Fundamentals.
Client Requirements#
The client is the receiver of the OTA image. It has two choices for the download space. The first is to use an external storage device, such as a serial dataflash, connected to the device. The second option, only available with devices with more than 512 kB flash space, is to use a portion of the main flash as the download space.
Bootloaders using the second option are often referred to as either internal or local storage bootloaders. For a full list of supported external memory parts for EFR32MGx parts, see UG489: Silicon Labs Gecko Bootloader User Guide or Silicon Labs Gecko Bootloader User’s Guide for Series 3 and Higher.
The following figure shows the different architectures and storage configurations for an OTA client. All are supported by the Silicon Labs Zigbee Stack.
The client software is based upon the ZCL Application Framework contained within the latest version of the Silicon Labs Zigbee PRO stack.
Further Reading#
The bootloader handles critical functions like initializing the device, updating firmware images, and performing integrity checks to ensure reliable updates. Silicon Labs recommends using the standard OTA Upgrade cluster defined in the Zigbee Cluster Library (ZCL), which works with the Gecko Bootloader to provide a complete OTA solution. The application implements the mechanism to obtain new code images, while the bootloader itself handles reading the GBL image from storage and copying it to the main flash. Fundamental knowledge of bootloading is required for any upgrade scenario. Below are some external references to bootloading, ZCL, and OTA image creation: