STM32WB Zigbee OTA

1 Introduction

The OTA is a feature that allows the update of Zigbee devices Over-The-Air. The OTA server offers the latest binary version for the OTA clients to download. The implementation of the OTA feature requires the use of the Exegin OTA Cluster.
See the Getting started with Zigbee® on STM32WB Series Application note .

2 STM32WB OTA use case

The Zigbee_OTA application is available by downloading the latest STM32CubeWB release.

The Zigbee OTA requires at least two STM32WBxx boards running the Zigbee protocol, with specific applications:

• One board running ZigBee_Ota_Server application (ZbZclOtaServer cluster allocated)
• One or more boards running ZigBee_Ota_Client application (ZbZclOtaClient cluster allocated)

Note that an OTA upgrade can be done for multiple clients in parallel.
First, the binary to download must be flashed on the “free” memory region on the server, by using STM32CubeProgrammer for example. In our use case, the binary is flashed at the address 0x08030000.
Then, the server initiates an OTA provisioning process, then proposes an update to the clients. They may then decide to upgrade or not. Multiple clients can be updated at the same time.
The binary must be transferred and flashed on the “free” memory region of the client. In our case, it will be flashed at the address 0x08030000.

OTA Server/Client model

During the application update, the server transfers the binary to the client. After receiving all the frames of the binary, the device reboots.
The binary is either for M4 application or for M0 coprocessor wireless binary.

2.1 Application update (M4)

The OTA verifies that the downloaded binary is for M4, and checks the integrity code. When done, the OTA launches the new application firmware (here On/Off app).

Application update

2.2 Coprocessor wireless binary update (M0)

If the downloaded binary is for coprocessor M0, the OTA checks the integrity code and reboots on FUS. When done, the wireless coprocessor installs the secure binary and reboots on the OTA. The OTA is now ready to receive the new M4 firmware which must always be updated and flashed after an M0 update.

Coprocessor wireless binary update

3 OTA Upgrade principle

The OTA upgrade is based on a specific file format composed of :

• OTA header
• OTA sub-element (Upgrade image tag + associated binary firmware data)

OTA File Format

The binary is stored in the flash memory on the server (at address 0x08030000 in our case). The server gets the CRC and the binary size, and then sends an image notification to all the clients in the network with mention of the image type and version. The clients must use the "Query Next Image" request if they want to get an upgrade. Upon receiving the "Query Next Image" request response, the client checks the device capabilities, before downloading the image. The client compares the free flash memory size with the requested image size.
The server cannot send the image as one block. The block size is limited:

• by the ZCL_OTA_BLOCK_DATA_SIZE_NWKSEC_MAX which is equal to 49 bytes, if network secured only, without APS secured
• and by ZCL_OTA_BLOCK_DATA_SIZE_APSSEC_MAX which is equal to 40 bytes if both network and APS are secured.
  

OTA Upgrade Diagram

4 OTA Cluster APIs Functions

The following table lists some examples of APIs used with OTA cluster.

Function	Description
ZbZclOtaClientAlloc	Create new OTA client cluster
ZbZclOtaServerAlloc	Create new OTA server cluster
ZbZclOtaClientDiscover	Discover OTA server
ZbZclOtaClientDiscoverForced	Set the OTA server directly
ZbZclOtaClientImageTransferResume	Resume an OTA upgrade transfer
ZbZclOtaClientImageTransferStart	Initiate an OTA transfer

5 Resuming a partial download

If for any reason the download of the binary is interrupted, the application can resume the transfer, depending on the reason for the interruption.

• If the OTA server turns off, the application waits until the reestablishment of the connection and resumes the transfer by calling ZbZclOtaClientImageTransferResume.
• If the OTA client turns off, after receiving and saving a part of the firmware, the transfer can be resumed from the previous download, using the FileOffset attribute.