Setting up a Client#

This option is only applicable to SOC (System-on-Chip) devices, not for NCP (Network Co-Processor) setups.

If enabled, the OTA client will perform GBL (bootloader) verification during the OTA update process. After the signature verification passes, the device will use the application bootloader routines to verify the GBL image. The update process may take slightly longer due to this additional verification step.

If disabled, the OTA client will not perform the additional GBL verification step. The device will rely solely on the signature verification process to validate the OTA image.

If enabled, the OTA client will include the current hardware version of the device in messages sent to the OTA server. This allows the server to consider the device's hardware compatibility when offering firmware updates. This is useful for managing updates across different hardware revisions of the same product.

If disabled, the OTA client will not include the hardware version information in messages to the OTA server. The server will not have explicit information about the device's hardware version when considering updates.

If enabled, the OTA client will delete any image (partial or complete) that has been downloaded but failed verification. It will also delete the image if the server instructs the client to abort the download or upgrade process. This helps conserve storage space and ensures that only valid and approved firmware images are kept on the device.

If disabled, the OTA client will retain failed or aborted download images on the device. This might be useful for debugging purposes or if there's a need to analyze failed updates. However, it may consume more storage space on the device over time.

If enabled, the OTA Client will automatically start when the Zigbee stack starts up, with a random delay of up to 5 minutes. This delay is implemented to avoid an issue where multiple devices in the network all query the server simultaneously after a power-outage.

If disabled, the OTA Client won't automatically start.

Download Delay determines how often a new block of data (or page) is requested during a download by the client.

A value of 0 means the client will request the blocks (or pages) as fast as the server responds.

If enabled, the client device uses an OTA Page Request command to ask for a large block of data all at once.

If disabled, the client device uses individual image block requests for each block of data.

If enabled, all received OTA images must be signed with an ECDSA (Elliptic Curve Digital Signature Algorithm) signature. The client verifies the signature once the download has completed, before applying the update.

If disabled, the OTA client does not perform signature verification on received images. Images are accepted and processed without checking for an ECDSA signature.

Verification Delay defines how often an ongoing verification process executes. When Signature verification is enabled this will control how often digest calculation is executed. Digest calculation can take quite a long time for an OTA image. Other processing for the system may be deemed more important and therefore we add delays between calculations. This also controls how often custom verification written by the application developer is executed.

A value of 0 means the calculations run to completion without any delays.

Minimum Block Period Units defines how the OTA client interprets the Minimum Block Period field in ImageBlockRequest and ImageBlockResponse messages during OTA updates. It has three possible settings:

• SECONDS: The client interprets the Minimum Block Period in seconds.
• MILLISECONDS: The client interprets the Minimum Block Period in milliseconds.
• DISABLE_FEATURE: This option disables the Minimum Block Period feature.

The Minimum Block Period is used to control the rate at which the client requests blocks of data during an OTA update process. This helps manage network traffic and prevents the client from overwhelming the server with too many requests in a short time.

If enabled, the OTA client will ignore any OTA server endpoints that are on the same device (loopback messages). It will only consider remote OTA servers during the server discovery process. This allows the client to discover and use OTA servers on other devices in the network. The first remote server to respond will be the one the client uses for OTA updates.

If disabled, the OTA client will consider all OTA server endpoints, including those on the same device. The client might not discover remote OTA servers if a local server endpoint responds first.

If enabled, the OTA client will only consider the Trust Center as a valid OTA server. This restricts OTA updates to come only from the Trust Center, which is typically the most secure device in the network.

If disabled, the OTA client will consider all OTA servers in the network, regardless of whether they are the Trust Center or not. This allows the client to use any available OTA server for updates.

OTA_CLIENT_SIGNER_EUI defines the EUI64 (Extended Unique Identifier, 64-bit) of an authorized signer for OTA images. The EUI64, represented as an array of 8 bytes (uint8_t), is used to verify the authenticity of downloaded OTA images. The OTA client will check if the signer of a received image matches this authorized EUI64 before accepting and installing the update.

OTA_CLIENT_SIGNER_EUI0 is the primary or default authorized signer EUI64.

The default value is the EUI64 of the test certificate embedded within the image-builder tool provided by Silicon Labs. Using this default will allow customers to test image signing and verification prior to obtaining production signing certificates from Certicom.

For production devices, you should use your own certificates and corresponding EUIs to ensure the security of your OTA update process.>/p

It sets the second authorized signer EUI64 for the OTA client.

The default value provided (all zeros) is effectively a null or invalid EUI64 and will be ignored.

In a production environment, you would replace this with your own authorized signer's EUI64 if you want to use multiple signers.

It sets the second authorized signer EUI64 for the OTA client.

The default value provided (all zeros) is effectively a null or invalid EUI64 and will be ignored.

In a production environment, you would replace this with your own authorized signer's EUI64 if you want to use multiple signers.