Firmware Update Examples and Models#

To perform firmware updates, you need an Initiator, a Distributor, and at least one Target node. This section describes the setup to run the Distributor and Target nodes examples provided in the Bluetooth mesh SDK, and the procedures to create an update image archive. See QSG183: Bluetooth Mesh SDK Quick-Start Guide for Bluetooth Mesh 1.1 for an introduction to configuring and building your own projects, and for a guide to additional resources.

The Initiator and Stand-alone Updater are not discussed in this document. However, these functionalities are demonstrated using the Silicon Labs Bluetooth Mesh mobile app, described in Firmware Update Demonstration and Firmware Update with Stand-alone Updater, respectively.

Firmware storage is an important part of the device firmware update process. The flash memory is managed by and accessed via the bootloader. See Bootloader Configurations for Firmware Updates for the flash configurations. The table in Appendix – Silicon Labs Product Positioning for Bluetooth Mesh DFU is a recommendation of the Silicon Labs parts for running the DFU roles.

Distributor Example Application#

The Distributor example application is provided as a pre-built demo binary image, ready to download and use, and a corresponding example project that you can modify and then build for the target part. The precompiled demo is only available for selected EFR32xG21 and EFR32xG24 parts.

This section describes how to build the example project and run the example application on a Silicon Labs device. The example is only available for a limited set of parts, including selected EFR32xG12, xG21 and xG24 parts.

Open Simplicity Studio 5 with a compatible SoC wireless kit connected to the computer. Select the part in Debug Adapters view to open the Launcher perspective.

  1. Click the Example Projects & Demos tab.

  2. To see only the example projects, turn off Demos.

  3. Under Technology Type, filter on Bluetooth Mesh.

  4. Next to the Bluetooth Mesh – SoC DFU Distributor, click CREATE, modify project settings, click FINISH.

  5. Build and flash the project to the device.

screenshotscreenshot

The example has the components that are required for the Distributor functionality installed by default. To enable the Distributor functionality in other Bluetooth mesh projects, install the DFU distributor component that automatically brings the necessary model components:

  1. Open the project .slcp file in Project Explorer view of the Simplicity IDE perspective.

  2. Click the Software Components tab.

  3. Select the DFU distributor component under Bluetooth Mesh > DFU Roles and click Install.

screenshotscreenshot

This component automatically installs the following model components:

  • Bluetooth Mesh > Models > Firmware Update > Firmware Distribution Server

  • Bluetooth Mesh > Models > Firmware Update > Firmware Update Client

  • Bluetooth Mesh > Models > Transport > BLOB Transfer Client

  • Bluetooth Mesh > Models > Transport > BLOB Transfer Server

See DFU Model Configurations for the configurations of these Firmware Update and BLOB Transfer models.

Target Node Applications#

A Target node is a node whose firmware is to be updated. The Bluetooth mesh examples provided in the Bluetooth mesh SDK except Bluetooth Mesh – NCP Empty and Bluetooth Mesh – SoC Empty have the firmware update functionality enabled by default, i.e., are Target nodes.

These example applications are provided both as prebuilt demo binary images, ready to download and use, and corresponding example projects that you can modify and then build for the target part. The precompiled demos are only available for a limited set of parts, including selected EFR32xG13, xG21 and xG24 parts and BGM13 and MGM21 modules. The examples can be built for any part supported by the Bluetooth Mesh SDK.

Note: EFR32xG22 parts have limited support for Bluetooth Mesh.

To build an example project for the device firmware update target, refer to the procedure described in Distributor Example Application.

screenshotscreenshot

The examples have the components that are required for the Target node functionality installed by default. To enable the Target node functionality in other Bluetooth mesh projects, install the DFU target node component that automatically brings the necessary model components:

  1. Open the project .slcp file in Project Explorer view of the Simplicity IDE perspective.

  2. Click the Software Components tab.

  3. Select the DFU target node component under Bluetooth Mesh > DFU Roles in the left panel and click Install.

screenshotscreenshot

This component automatically installs the following model components:

  • Bluetooth Mesh > Models > Firmware Update > Firmware Update Server

  • Bluetooth Mesh > Models > Transport > BLOB Transfer Server

See the section below for the configurations of these Firmware Update and BLOB Transfer models.

DFU Model Configurations#

This section describes the main settings of the Firmware Update and BLOB Transfer models. Open the project .slcp file in Project Explorer view of the Simplicity IDE perspective.

  1. Click the Software Components tab.

  2. Select Bluetooth Mesh > Models > Firmware Update or Bluetooth Mesh > Models > Transport in the left panel.

  3. Click the gear icon next to the model to be configured.

Firmware Distribution Server#

Configuration of Bluetooth Mesh > Models > Firmware Update > Firmware Distribution Server:

Configuration Option Description Default Value
Max node list size Maximum number of firmware update server nodes which can participate in the distribution. Range: 1 to 65535. 8
Default Multicast Threshold If the number of servers for any step exceeds or is equal to this number then the group address will be used, otherwise servers will be looped through one by one. Range: 1 to 65535. The value of 0 disables the feature. 1
Retry time of message transmissions Retry time of firmware update message transmissions. Range: 0 to 65535. 3000
NVM key of the firmware list NVM key of the firmware list. Range: 0 to 65535. 16393
Enable Logging Enable / disable logging of Firmware Distribution Server model specific messages. On

Enable Logging:

Enable BT Mesh Stack Platform Callback Logging

Enable / disable logging of BT Mesh Stack Firmware Distribution Server model platform callbacks. The FW Distribution Server model in BT Mesh stack calls platform callback functions to query the remaining space, firmware count and firmware information. Off

Enable Logging:

Text prepended to every log message

Every log message in the component is started with this text. FwDistributor

Firmware Update Server#

Configuration of Bluetooth Mesh > Models > Firmware Update > Firmware Update Server:

Configuration Option Description Default Value
General
Number of firmware on device Number of firmware on device. Range: 1 to 255. 1
Maximum length of metadata Maximum length of metadata. Range: 0 to 255. 255 / LPN:31
Firmware Information
Firmware identifier Firmware identifier fwid or <specific_node_id>
Update URI Update URI https://example.com/upd_uri
Company Identifier: CID MSB Most Significant Byte of the Company ID. Hexadecimal string literal. \x02
Company Identifier: CID LSB Least Significant Byte of the Company ID. Hexadecimal string literal. \xFF

The weak functions for the Firmware Update Server model are mostly implementation-dependent and can be overwritten in the application:

Function

Description

sl_btmesh_fw_update_server_metadata_check_start()

User callback indicating start of metadata check

sl_btmesh_firmware_update_server_metadata_check_step()

User callback executing one step of metadata check

sl_btmesh_fw_update_server_verify_start()

User callback for determining the maximum chunk size of verification

sl_btmesh_fw_update_server_verify_step()

User callback to execute one step of the verification

sl_btmesh_fw_update_server_apply()

User callback indicating firmware apply request

See <sdk>/app/bluetooth/common/btmesh_firmware_update_server/sl_btmesh_firmware_update_server_api.h for further information.

A Target node will become unprovisioned by default after a firmware update. You can overwrite the following functions in sl_btmesh_firmware_update_server_api.c and modify the code described below to change the behavior:

  • sl_btmesh_fw_update_server_apply() – remove sl_btmesh_node_reset() and sl_bt_nvm_erase_all().

    if (BOOTLOADER_OK == bootloader_setImageToBootload(idx)) {
      // Reset node
      sl_btmesh_node_reset();
      // Erase NVM data
      sl_bt_nvm_erase_all();
      // Delay install
      sl_simple_timer_start(&timer, 1000, apply_step, NULL, true);
      apply_cntdwn = APPLY_DELAY;
    }
  • sl_btmesh_fw_update_server_metadata_check_start() – set another value to *additional_information. The additional information is provided to the Bluetooth mesh stack and will appear in the Firmware Update Status and Firmware Update Firmware Metadata Status messages.

    *additional_information = BTMESH_FW_UPDATE_SERVER_ADDITIONAL_INFORMATION_UNPROVISION;
  • sl_btmesh_firmware_update_server_metadata_check_step() – set another value to *additional_information. The additional information is provided to the Bluetooth mesh stack and will appear in the Firmware Update Status and Firmware Update Firmware Metadata Status messages.

    *additional_information = BTMESH_FW_UPDATE_SERVER_ADDITIONAL_INFORMATION_UNPROVISION;

BLOB Transfer Client#

Configuration of Bluetooth Mesh > Models > Transport > BLOB Transfer Client:

Configuration Option Description Default Value
Enable Logging Enable / disable logging of BLOB Transfer Client model specific messages. On

Enable Logging:

Text prepended to every log message

Every log message in the component is started with this text. BlobTfClient

Enable Logging:

Log BLOB Status messages

Log the content of BT Mesh BLOB status messages. 1

BLOB Transfer Limits:

Max number of servers

Maximum number of BLOB transfer servers that can be serviced in a transfer (affects BT Mesh stack memory usage). Range: 1 to 1008. 8

BLOB Transfer Limits:

Max number of blocks

Maximum number of blocks supported in a BLOB Transfer (affects BT Mesh stack memory usage). Range: 1 to 1888. 1850

BLOB Transfer Limits:

Max number of chunks per block

Maximum number of chunks per block supported in a BLOB Transfer (affects BT Mesh stack memory usage). Range: 1 to 2000. 128

BLOB Transfer Limits:

Max chunk size

Maximum chunk size that can be selected during BLOB Transfer. Range: 1 to 241. 241

Retry and Separation parameters:

Default separation time between chunks

Default minimum separation time between two chunks in the same block. Range: 0 to 65535. 0

Retry and Separation parameters:

Default max retry of message transmissions

Default max retries of message transmissions (query info, transfer start, block start, block query). Range: 0 to 1000. 50

Retry and Separation parameters:

Default retry time of message transmissions

Default retry time of message transmissions (query info, transfer start, block start, block query). Range: 0 to 65535. 2000

The weak functions for the BLOB Transfer Client model are mostly implementation-dependent and can be overwritten in the application:

Function

Description

sl_btmesh_blob_transfer_client_calculate_block_size_log()

Calculates the binary logarithm of the block size for the current BLOB transfer from the provided parameters, which are the result of the Retrieve Capabilities procedure of the BLOB Transfer. The parameters passed represent the aggregated capabilities of the BLOB transfer client and every BLOB transfer server which participates in the current transfer. The default implementation calculates the greatest possible block size from the parameters.

sl_btmesh_blob_transfer_client_calculate_chunk_size()

Calculates the chunk size for the next block in the current BLOB transfer from the previously selected binary logarithm of the block size and from the result of the Retrieve Capabilities procedure of the BLOB Transfer. The default implementation calculates the greatest possible chunk size.

See <sdk>/app/bluetooth/common/btmesh_blob_transfer_client/sl_btmesh_blob_transfer_client.h for further information.

BLOB Transfer Server#

Configuration of Bluetooth Mesh > Models > Transport > BLOB Transfer Server:

Configuration Option Description Default Value
General
Min Block Size Log Block states need to be monitored. The smaller the blocks, the bigger the state storage. Range: 6 to 32. Note that decreasing the minimum block size will result in increased heap usage. Change this value with care. 9
Max Block Size Log Blocks are cached on heap before being written into NVM. Range: 6 to 32. Note that increasing the maximum block size will result in increased heap usage. Change this value with care. 9
Maximum of number of chunks per block Maximum of number of chunks per block. Range: 8 to 64. Step: 8. 16 / LPN:64
Maximum chunk size

If the max chunk size is 8, the chunk data fits into a single BT Mesh advertisement message. If the chunk data is segmented, N segments can transfer (N*12)-7 bytes of data. Range: 8 to 241.

The advantage of a higher chunk size is higher throughput in a low noise environment. The advantage of a lower chunk size is fewer messages are retransmitted in a high noise environment due to lost chunk messages.

LPN only: the number of chunk messages (segments) multiplied by requested chunk count in Partial Block Report should fit into the friend queue.

241 / LPN:8
Logging Enable / disable logging of BLOB Transfer Server model-specific messages. On
Transfer Start user callback Enable / disable callback function when BLOB transfer starts. On
Transfer Progress user callback Enable / disable callback function when block transfer is finished. On
Transfer Done user callback Enable / disable callback function when BLOB transfer is finished. On
Supported Transfer Modes
Push Mode Push BLOB Transfer Mode. On / LPN: Off
Pull Mode Pull BLOB Transfer Mode. On

Pull Mode:

Number of chunks requested in Block Status or Partial Block Report

Number of chunks requested in Block Status or Partial Block Report. Range: 1 to 32. 4

Pull Mode:

Interval, in milliseconds, between Partial Block Reports, if nothing is received

Interval, in milliseconds, between Partial Block Reports, if nothing is received. Range: 1000 to 30000. Step: 100. 1000

Pull Mode:

Number of retries sending the same Partial Block Report, before giving up

Number of retries sending the same Partial Block Report, before giving up. Range: 1 to 10. 8

Pull Mode:

LPN Mode

Used on LPN nodes. Off / LPN:On

Pull Mode - LPN Mode:

LPN high throughput mode

In high throughput mode the LPN node polls the friend node more frequently to increase the throughput at the expense of power consumption. On

Pull Mode - LPN Mode - LPN high throughput mode:

LPN poll delay in milliseconds

The delay of first LPN poll when the BLOB Transfer Server expects messages from the client after an event. The major part of BLOB transfer to LPN is waiting for the poll timeout to elapse in order to poll the friend node for BLOB Transfer messages. The maximum number of messages that can be transferred per polling is equal to the friend queue size during BLOB transfer to LPN. This poll delay parameter makes the polling more frequent when BLOB Transfer messages are expected to increase the throughput. Range: 100 to 30000. Step: 100. The LPN poll delay should be less than SL_BTMESH_LPN_POLL_TIMEOUT_CFG_VAL in sl_btmesh_lpn_config.h file. 500

Creating the Update Image Archive#

An update image archive is a gzip archive file that consists of:

  • Manifest: a file named manifest.json, which is in the format of JavaScript Object Notation (JSON). It contains a description of the firmware package, including the name of the firmware image file and an optional metadata file for the update.

  • Firmware Image: the firmware image file in GBL format, as identified in the manifest file.

  • Metadata: an optional file provided by the vendor and identified in the manifest file, that may provide metadata for the firmware image.

This section describes the procedure to generate a firmware image, manifest file, and update image archive.

Step 1: generating a firmware image#

Building a C-based Bluetooth mesh application in Simplicity Studio does not automatically generate the OTA DFU update images (GBL files). The GBL files need to be created separately by running a script located in the project's root folder. Two scripts are provided in the SDK examples:

  • create_bl_files.bat (for Windows)

  • create_bl_files.sh (for Linux / Mac)

Define two environmental variables, PATH_SCMD and PATH_GCCARM shown in the following table, before running the script.

Variable Name

Variable Value

PATH_SCMD

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\commander

PATH_GCCARM

C:\SiliconLabs\SimplicityStudio\v5\developer\toolchains\gnu_arm\7.2_2017q4

Running the create_bl_files script creates six GBL files in a subfolder named output_gbl. The file named application.gbl is the firmware update image.

If you use a bootloader that supports LZMA compression of the firmware update image, as described in Compressed Update Image, you must compress the GBL file with the –compress option of the commander utility. The create_bl_files script does not support compressed GBL update image generation. Therefore, run the following commands instead of the create_bl_files script and then the file named application-lzma.gbl is the firmware update image. Change soc_btmesh_empty.axf to the name of your project firmware image in the command line below.

arm-none-eabi-objcopy -O srec -R .text_apploader* -R .text_signature* soc_btmesh_empty.axf application.srec
commander gbl create application-lzma.gbl --app application.srec --compress lzma

For more information about the GBL file format, see Silicon Labs Gecko Bootloader User’s Guide for GSDK 4.0 and Higher (series 1 and 2 devices). For more information on using the Simplicity Commander commands, see Simplicity Commander Reference Guide.

Step 2: creating a manifest file#

Create a file named manifest.json that is a text file in JSON format containing the name of the firmware update image, the firmware ID and optionally the name of the metadata file. The format of the manifest/firmware/firmware_id member is Base16. The manifest/firmware/metadata_file member contains the metadata file name if present. The following is an example of the content of the manifest.json file.

{
    "manifest": {
        "firmware": {
            "firmware_file": "application.gbl",
            "firmware_id": "4181C01592"
        }
    }
}

Step 3 – making an update image archive#

Run the following command to generate a zipped tar archive:

tar czf firmware.gz application.gbl manifest.json