ZigBee over-the-air upgrade
An over-the-air (OTA) upgrade involves transferring a new firmware image to a device already installed and operational within a ZigBee network. This functionality is provided by the OTA upgrade cluster. To upgrade the devices on a network, two functional elements are required as follows:
OTA Server: First, the network must host an OTA server, which receives new OTA images from manufacturers and advertise the OTA image details to the network. Then, it must deliver the new image to the requested devices.
OTA Clients: The second requirement is for OTA clients, which are on the network devices that can be updated. These devices periodically interrogate the OTA server for details of the firmware images available. If a client finds a suitable upgrade image on the server, it starts to request this image, storing each part as it is received. Once the full image has been received, it validates, and the device boots to run the new image.
The clients pull down the new images, requesting each block in turn and filling in the gaps. The server never pushes the images onto the network.
OTA for RW612 platform
For information about the over-the-air upgrade process for RW612 platforms, refer to the section Zigbee Over The Air Upgrade (OTA) for RW612 platforms.
Overview
Support for the OTA upgrade cluster as a client has been included for the Router and End Device.
Note: By default, all the devices only support encrypted OTA.
The internal flash memory is used to store the upgraded image by default.
The table below shows that the initial client binaries to be programmed into the K32W1, MCXW71, and MCXW72 devices are version 1 files.
Version 1 files
Hardware platform |
Binary files |
|---|---|
K32W148-EVK board |
• |
FRDM-MCXW71 board |
• |
MCX-W72-EVK board |
• |
The table below shows that the OTA images are the V2/V3.ota files.
V2/V3 OTA files
Hardware platform |
OTA files |
|---|---|
K32W148-EVK board |
• |
FRDM-MCXW71 board |
• |
MCX-W72-EVK board |
• |
Parent topic:ZigBee over-the-air upgrade |
OTA upgrade operation
This section describes the OTA upgrade operation for K32W148-EVK, FRDM-MCXW71, or MCX-W72-EVK boards.
For information about the over-the-air upgrade process for RW612 platforms, refer to the section, Zigbee Over The Air Upgrade (OTA) for RW612 platforms.
To add an image to the coordinator, the OTA images must be programmed. To program the OTA images, perform the following steps:
Use the J-Link utility.
Download
J-Linkfrom J-Link / J-Trace Downloads.Plug the K32W148-EVK, FRDM-MCXW71, or the MCX-W72-EVK board to the USB port (no need to keep the SW4 button pressed while doing this step).
Create a
commands_scriptfile with the following content (change the application name as necessary):Reset Halt LoadBin <OTA_ADDRESS> 0x7A000 Reset Go Quit
Where
OTA_ADDRESSvalue:for K32W1/FRDM-MCXW71 OTA_ADDRESS = 0x7A000
for MCX-W72-EVK OTA_ADDRESS = 0xFA000 Note: If J-Link fails to recognize the
.otafile, rename it to.binand retry.
Copy the application and
commands_scriptin the same folder where the J-Link executable is placed.Run the following code:
JLink.exe/JLinkExe (linux) -<DEVICE_NAME> -if SWD -speed 4000 -autoconnect 1 -CommanderScript commands_script
Where
DEVICE_NAMEcan be:K32W1480 for K32W1
MCXW716 for MCXW71
MCXW727C_CORE0 for MCXW72
When adding an image to a non-factory new coordinator, care must be taken not to use the Erase command to erase the flash.
Any devices with OTA clients in the network periodically send match descriptor requests to find an OTA server. Once a server responds, it then sends an IEEE address request to confirm the address details. The clients then periodically send OTA Image Requests to determine whether the server is hosting an image for that client device. In response to the Image Request, the server returns details of the image that it currently hosts: Manufacturer code, Image tag, and Version number. The client checks these credentials and decides whether it requires this image. If it does not, it queries the server again at the next query interval. If the client does require the image, it starts to issue Block Requests to the server to get the new image. Once all blocks of the new image have been requested and received, the new image is verified. The older image is invalidated, the device reboots, and runs the new image. The client resumes periodically querying the server for new images.
The End Device, which is RX Off, is allowed to enter Sleep mode. It stays awake for 5 seconds and then sleeps for 1 second when not performing “Finding and Binding”.
Parent topic:ZigBee over-the-air upgrade
Image credentials
Four main elements of the OTA header are used to identify the image to enable the OTA client to decide whether it must download the image.
Manufacturer code: This element is a 16-bit number that is a ZigBee-assigned identifier for each member company. In this application, this number has been set to 0x1037, which is the identifier for NXP. In the final product, this number must be changed to the identifier of the manufacturer. The OTA client compares the Manufacturer code in the advertised image with its own and the image downloads only if they match.
Image type: This element is a manufacturer-specific 16-bit number in the range 0x0000 to 0xFFBF. It is used by the manufacturer to distinguish between devices. In this application, the Image type is normally set to the ZigBee Device Type. However, this application uses 0x0003 for the Router and End Device. The OTA client compares the advertised Image type with its own Image type. If the Image type matches, then the image is downloaded. The product designers are entirely free to implement an identification scheme of their own.
File version: This element is a 32-bit number representing the version of the image. The OTA client compares the advertised version with its current version before deciding whether to download the image.
OTA header string: This element is a 32-byte character string and its use is manufacturer-specific. In this application, the OTA client compares the string in the advertised image with its own string before accepting an image for download. If the strings match, then the image is accepted. In this way, the string can be used to provide extra detail for identifying images, such as hardware subtypes.
Parent topic:ZigBee over-the-air upgrade
Upgrade and downgrade
The decision to accept an image following a query response is under the control of the application. The code, as supplied, accepts an upgrade or a downgrade. As long as the notified image has the right credentials and a version number, which is different from the current version number, the image is downloaded.
For example, if a client is running a v3 image and a server is loaded with a v2 image then the v2 image is downloaded. The application callbacks the function responsible for handling the image in the following two scenarios:
When the client is required to accept only the upgraded images (v2 > v3 > v5)
When the client is required to accept only the sequential upgrade images (v2 > v3 > v4 > v5)
.
Parent topic:ZigBee over-the-air upgrade