AN1086: Using the Gecko Bootloader with the Silicon Labs Bluetooth® Applications

2.1 UART DFU Options

The target device must be programmed with the Gecko Bootloader sample project Bootloader - NCP BGAPI UART DFU. The Gecko Bootloader is configured automatically for the selected radio board. The BGAPI UART DFU bootloader is a standalone bootloader, so no storage area needs to be configured. During UART DFU upgrade, the bootloader writes the new firmware image directly on top of the old firmware image, and therefore no temporary download area is needed.

GPIO Settings

The default settings are suitable for testing with a WSTK (Wireless Starter Kit). These settings can be easily changed through the Software Components tab. Select the Bootloader UART driver component. Here, Hardware Flow Control can be enabled or disabled, and the baud rate and pinout can be configured.

Flow control settings of the radio board and the WSTK must match. The WSTK's flow control can be configured as follows:

• In Simplicity Studio's Debug Adapters view, right-click on the connected device.
• Select Launch Console.
• In the Admin tab, type 'serial vcom config handshake disable/enable', depending on whether you want to disable or enable flow control.

2.2 UART DFU Process

The basic steps involved in the UART DFU, using NCP, are as follows:

1. Boot the target device into DFU mode by calling the bootloader API bootloader_rebootAndInstall(). In NCP-mode, this can be achieved by calling sl_bt_system_reset_to_dfu(). When using Series 1 devices, reset into DFU is achieved with sl_bt_system_reset(1). Alternatively, if you have GPIO activation enabled in the bootloader, press the bootloader activation pin while the device is reset.
2. Wait for the DFU boot event.
3. Send the command DFU Flash Set Address to start the firmware upgrade.
4. Send the entire contents of the GBL upgrade image (using the command DFU flash upload).
5. After sending all data, the host sends the command DFU flash upload finish.
6. To finalize the upgrade, the host resets the target device into normal mode (by sending sl_bt_system_reset(0)).

A detailed description of the DFU-related BGAPI commands is found in the Bluetooth Software API Reference Manual.

At the beginning of the upgrade, the NCP host uses the command Flash Set Address to define the start address. The start address shall always be set to zero. During the data upload (step 4 above), the target device calculates the flash offset automatically. The host does not need to explicitly set any write offset.

The UART DFU procedure may fail if the update image is either corrupted or data upload is interrupted for some reason. Failure due to either of these conditions is detected by the CRC check performed by the UART DFU bootloader before jumping into the main program. In this case, a dfu_boot_failure event is sent by the stack. The returned reason codes align with the sl_status codes, as shown in the platform documentation.

2.3 Creating Upgrade Images for the Bluetooth NCP Application

Building a C-based NCP project in Simplicity Studio does not generate the UART DFU upgrade images (GBL files) automatically. The GBL files need to be created separately by running a script located in the application project's root folder. Before running the script, the application must be compiled.

Two scripts are provided in the SDK examples:

• create_bl_files.bat (for Windows)
• create_bl_files.sh (for Linux / Mac)

The GBL files can be generated by invoking the script from the project directory.

You need to define two environment variables, PATH_SCMD and PATH_GCCARM, before running the script, as shown in the following table:

Running the create_bl_files script creates multiple GBL files in a subfolder named output_gbl. The file named full.gbl is the upgrade image used for UART DFU. The other files are related to OTA upgrades, and they can be ignored.

If signing and/or encryption keys (named app-sign-key.pem, app-encrypt-key.txt) are present in the same directory, then the script also creates secure variants of the GBL files. More information on creating secure firmware for DFU can be found in the training document: Secure Firmware Upgrade using OTA.

2.4 UART DFU Host Example

The UART DFU host example is a C program that is located under the Bluetooth SDK examples in the following directory (the exact path depends on the installed SDK version).

In Windows, this program can be built using MinGW. In Linux or Mac, the program can be built using the GCC toolchain.

The project is built by running make (or mingw32-make) in the project root directory. After a successful build, an executable is created in the subfolder named exe. The executable filename is bt_host_uart_dfu.exe.

Before running the example, you need to check the COM port number associated with your NCP target. For more details, see AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode.

The bt_host_uart_dfu.exe program requires three command-line arguments:

• COM port number
• Baud rate
• Name of the (full) GBL file

Furthermore, the device must be flashed with the BGAPI UART DFU Bootloader and an NCP-application.

Example usage and expected output in v4.0 or higher:

./bt_host_uart_dfu.exe -u COM42 -b 115200 full.gbl

Expected output:

[I] NCP host initialized.
[I] Reset NCP target in bootloader mode...
[I] DFU booted: v0x02010000
[I] Pressing Ctrl+C aborts the update process.
[I] WARNING! If the update process is aborted, the device will stay in bootloader mode.
207728/207728 (100%)
[I] DFU finished successfully. Resetting the device.

The number of bytes uploaded in one DFU flash upload command is configurable. The UART DFU host example included in the SDK uses a 48-byte payload. The maximum usable payload length is 128 bytes. The maximum number of bytes sent in one command is specified using a C preprocessor directive named MAX_DFU_PACKET. The value of MAX_DFU_PACKET must be divisible by four.

3.1 AppLoader

A Bluetooth application developed with Silicon Labs Bluetooth SDK comprises two parts: AppLoader and the user application. AppLoader is a small standalone application that is required to support in-place OTA updates. AppLoader can run independently of the user application. It contains a minimal version of the Bluetooth stack, including only those features that are necessary to perform the OTA update. Any Bluetooth features that are not necessary to support OTA updates are disabled in AppLoader to minimize the flash footprint.

The AppLoader features and limitations are summarized below:

• Enables OTA updating of user application.
• The AppLoader itself can also be updated.
• Only one Bluetooth connection is supported, GATT server role only.
• Encryption and other security features such as bonding are not supported.
• PTI is not enabled, so it is not possible to use the Network Analyzer with the AppLoader.

Note: AppLoader in SDK v3.x or higher requires that the Gecko Bootloader version must be v1.11 or later to support OTA.

The user application is placed in code flash after AppLoader. The default linker script provided in the SDK places the user application so that it starts at the next flash sector following AppLoader. The user application contains a full-featured version of the Bluetooth stack and can run independently of the AppLoader. If in-place OTA update does not need to be supported, then the AppLoader can be removed completely to free up flash for other use (code space or data storage). Section 5. Implementing Device Firmware Update in the User Application describes how OTA can be implemented in application code, without any involvement of AppLoader.

For more details on AppLoader and the overall structure of a Bluetooth application, see UG434: Silicon Labs Bluetooth® C Application Developers Guide for SDK v3.x or UG136: Silicon Labs Bluetooth® C Application Developers Guide for SDK v2.x.

3.2 Gecko Bootloader Configuration up to SDK version 3.3.x

The Gecko Bootloader must be configured as an application bootloader. The OTA functionality is implemented almost entirely in the AppLoader, or alternatively in the user application. The Gecko Bootloader takes care of copying data from the download area to the final destination in flash. Additionally, AppLoader takes advantage of some features supported by Gecko Bootloader, for example, parsing the incoming GBL image.

Note: Gecko Bootloader has an Application upgrade version check component/plugin that can be included in the Bootloader project. This feature is used to check the version number and product ID of the application upgrade before applying it. However, this should not be used with AppLoader because the version comparison is done to AppLoader instead of the application.

For EFR32xG1, the Bluetooth in-place OTA DFU Bootloader configuration is used as a default. In this configuration, the upper half of the main flash, normally used to hold the Bluetooth application, is re-purposed as a storage area while a Bluetooth stack upgrade is downloaded.

For EFR32xG12 and later, any application bootloader configuration may be used that uses internal storage. The default example application configurations are suitable for Bluetooth OTA upgrades and may be modified to fit the needs of the application. The following figure shows an example flash layout for EFR32xG1 and EFR32xG12 devices. For more information on flash organization, see UG434: Silicon Labs Bluetooth® C Application Developers Guide for SDK v3.x or UG136: Silicon Labs Bluetooth® C Application Developers Guide for SDK v2.x.

Note: On Series 2 devices (EFR32xG2x), the default NVM solution is NVM3, and NVM3 might also be used instead of PS Store on Series 1 devices. In this case, the NVM area is larger than 4 kB, and therefore the slot size in the bootloader configuration must be reduced accordingly to avoid overwriting the NVM area.

3.3 Gecko Bootloader Configuration from SDK version 4.0

From Bluetooth SDK version v4.0, the AppLoader can also be included in the Bootloader. The following picture shows an example of this new layout:

To use the AppLoader from the Bootloader, the start address of the Bootloader upgrade location needs to be changed so that there will be enough space for the Bootloader with the AppLoader. Unfortunately, this is not possible on Series 1 devices since the default Bootloader upgrade location is defined in the first stage Bootloader. So, this new method can only be used on Series 2 devices. For Series 2 devices, this is the new default configuration.

3.4 In-Place OTA Process

Most of the OTA functionality is handled autonomously by the AppLoader, which greatly simplifies application development. The minimum requirement for the user application is for a way to trigger a reboot into DFU mode. Rebooting into DFU mode in this context means that after the device is reset, the AppLoader is run instead of the user application. After the upload is complete, AppLoader will reboot the device back into normal mode.

Reboot into DFU mode can be triggered in a variety of ways. It is up to the application developer to decide which is most applicable. Most of the example applications provided in the Bluetooth SDK already have OTA support built into the code. In these examples, the DFU mode is triggered through the Silicon Labs OTA service that is included as part of the application's GATT database. The following sections explain in detail how this is done in the user application.

AppLoader supports two types of update:

• Full update: both AppLoader and the user application are updated
• Partial update: only the user application is updated

Note: In earlier stack versions (SDK v2.6.x and earlier), the meaning of partial and full update is different compared to the current OTA implementation. To avoid confusion, the main differences between the old and new OTA are summarized below.

(1) A full update is always recommended when moving from one SDK version to another. The size of AppLoader can vary depending on the SDK version. This may prevent a partial OTA update if the new application image overlaps with the old AppLoader version.

From the OTA client viewpoint, the overall OTA process is the same in both old and new versions. Full update is performed by uploading two GBL files into the target device. Partial update requires only one file. Because the mechanism of uploading GBL files over the air is identical, the OTA solution introduced in SDK 2.7.0 is backwards-compatible:

• Device running an application from SDK v2.6.x (or older, down to 2.0.x) can be upgraded to 2.7.x using OTA
• Device running v2.7.x firmware can be downgraded to 2.6.x or older using OTA
• Device running an application from SDK v2.7.x firmware and Gecko Bootloader v1.11 or later can be upgraded to SDK v3.x using OTA

The partial update process using AppLoader consists of the following steps:

1. OTA client connects to target device.
2. Client requests target device to reboot into DFU mode.
3. After reboot, client connects again.
4. During the 2nd connection, target device is running AppLoader (not the user application).
5. New firmware image (application.gbl) is uploaded to the target.
6. AppLoader copies the new application on top of the existing application.
7. When upload is finished and connection closed, AppLoader reboots back to normal mode.
8. Update complete.

With partial update, it is possible to update the Bluetooth stack and user application. AppLoader is not modified during partial update.

Full update enables updating both the AppLoader and the user application. Full update is done in two steps. Updating the AppLoader always erases the user application and therefore AppLoader update must always be followed by application update.

The first phase of full update updates the AppLoader and it consists of the following steps:

1. OTA client connects to target device.
2. Client requests target device to reboot into DFU mode.
3. After reboot, client connects again.
4. During the 2nd connection, target device is running AppLoader (not the user application).
5. New AppLoader image (apploader.gbl) is uploaded to the target.
6. AppLoader copies the image into the download area (specified in Gecko bootloader configuration).
7. When upload is finished and connection closed, AppLoader reboots and requests Gecko Bootloader to install the downloaded image.
8. Gecko Bootloader updates AppLoader using the downloaded image and reboots.
9. After reboot, the new AppLoader is started.

At the end of the AppLoader update, the device does not contain a valid user application and therefore AppLoader will remain in DFU mode. To complete the update, a new user application is uploaded following the same sequence of operations that were described for the partial update.

The SDK includes an example OTA client implementation that can be used to perform both full and partial updates. This example app is described in section 3.12 OTA DFU Host Example. Full and partial OTA can also be performed using the EFR Connect smartphone app.

3.5 Silicon Labs OTA GATT service

The following XML representation defines the Silicon Labs OTA service. It is a custom service using 128-bit UUID values. The service content and the UUID values are fixed and must not be changed.

The OTA service characteristics are described in the following table. The UUID value of the service itself is 1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0.

Notes:

• (1) This characteristic is excluded from the user application GATT database.
• (2) Version information is automatically added by AppLoader when running in DFU mode. These are optional in the application GATT database.
• (3) This characteristic exposes AppLoader version starting from SDK 2.7.0; was stack version in earlier versions.
• (4) Silicon Labs highly recommends that the default property (i.e., write) be used only over bonded connections to prevent uploading of new firmware by untrusted/unknown devices.

In DFU mode, AppLoader uses the full OTA service described above. This allows a remote Bluetooth device to upload a new firmware image, as described later in this chapter. The GATT database of the user application includes only a subset of the full OTA service. The minimum application requirement is to include the OTA control characteristic. The application must not include the OTA data characteristic in its GATT database (unless the OTA update is implemented fully in application code, as described in section 5. Implementing Device Firmware Update in the User Application).

From the user application viewpoint, only the OTA control attribute is relevant. In the OTA host example reference implementation that is included in the SDK, the OTA procedure is triggered when the client writes value 0 to the OTA control attribute. The user application does not handle any data transfers related to OTA upgrades and therefore the OTA Data Attribute is excluded from the user application's GATT.

3.6 OTA GATT Database and Generic Attribute Service

When booted into DFU mode, the AppLoader uses a GATT database that is different than the normal GATT used by the application.

The OTA DFU GATT database used by AppLoader contains the following services:

• Generic Attribute (UUID 0x1801)
• Generic Access (UUID 0x1800)
• Silicon Labs OTA service (UUID 0x1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0)

The Bluetooth specification requires that, if GATT-based services can change in the lifetime of the device, then the Generic Attribute Service (UUID 0x1801) and the Service Changed characteristic (UUID 0x2A05) shall exist in the GATT database. For details, please see Bluetooth Core specification, Version 5.2, Vol. 3, Part G, 7 DEFINED GENERIC ATTRIBUTE PROFILE SERVICE.

The Generic Attribute service is automatically included in the AppLoader GATT database used during OTA. To avoid any interoperability issues due to GATT caching, it is strongly recommended that the application GATT database used in normal mode also enables this service. Generic Attribute service is enabled by default in the SDK example applications.

Note: AppLoader does not generate a service changed indication when rebooting to DFU mode or rebooting back to normal mode. Automatic service changed indication requires that the client is bonded and has enabled the indication for this characteristic. AppLoader does not support bonding and therefore the service changed indication is not generated.

The Generic Attribute Service can also be explicitly defined in the application's GATT database using the same XML notation that is used for other services. The Generic Attribute service must be the first service in the list, to ensure it is aligned with the Generic Attribute Service that is used during OTA. The Bluetooth specification requires that the attribute handle of the Service Changed characteristic shall not change and therefore this service must be first on the list (the same as in the OTA GATT database).

More details on the Generic Attribute Service can be found on the Bluetooth SIG website: https://www.bluetooth.com/specifications/gatt/services

Note also that AppLoader does not support the GATT caching enhancements that were introduced in the Bluetooth Core Specification 5.1 and Silicon Labs Bluetooth SDK 2.11.1.

3.7 Triggering Reboot into DFU Mode from the User Application

The minimum functional requirement to enable OTA in the user application is to implement a 'hook' that allows the device to be rebooted into DFU mode. By default, this is done through the Silicon Labs OTA service.

The following code snippet is from the SoC Thermometer example supplied with the SDK. The code to enter DFU mode is similar in the other examples.

// This event indicates that a remote GATT client is attempting to write //
// a value of a user type attribute in to the local GATT database.
case sl_bt_evt_gatt_server_user_write_request_id:
  // If user-type OTA Control Characteristic was written, boot the device
  // into Device Firmware Upgrade (DFU) mode.
  if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_ota_control) {
    // Set flag to enter OTA mode.
    boot_to_dfu = true;
    // Send response to user write request.
    sc = sl_bt_gatt_server_send_user_write_response(
        evt->data.evt_gatt_server_user_write_request.connection,
        gattdb_ota_control,
        SL_STATUS_OK);
    app_assert(sc == SL_STATUS_OK,
               "[E: 0x%04x] Failed to send response to user write request\n",
               (int)sc);
    // Close connection to enter to DFU OTA mode
    sc = sl_bt_connection_close(
        evt->data.evt_gatt_server_user_write_request.connection);
    app_assert(sc == SL_STATUS_OK,
               "[E: 0x%04x] Failed to close connection to enter to DFU OTA mode\n",
               (int)sc);
  }
  break;

// This event indicates that a connection was closed.
case sl_bt_evt_connection_closed_id:
  // Check if need to boot to OTA DFU mode.
  if (boot_to_dfu) {
    // Reset MCU and enter OTA DFU mode.
    sl_bt_system_reset(2);
  }
  break;

In v3.x and higher: The event with ID sl_bt_evt_gatt_server_user_write_request_id indicates that one of the characteristics (of type user) has been written by the remote Bluetooth client. This event handler is found in the ota_dfu.c file, which is part of the OTA DFU component.

In v2.x: The event with ID gecko_evt_gatt_server_user_write_request_id indicates that one of the characteristics (of type user) has been written by the remote Bluetooth client. This event handler is normally included in the app.c file of the sample projects.

In this example, the code simply checks if the OTA control characteristic was written and, if so, triggers a reboot into DFU mode. Before rebooting, the application closes the Bluetooth connection. The variable boot_to_dfu is set to indicate that DFU reboot has been requested. When the connection closed event is raised by the stack, the application checks the variable boot_to_dfu and if set, performs the DFU reboot by calling sl_bt_system_reset(2) in v3.x and higher, and gecko_cmd_system_reset(2) in v2.x. Parameter value 2 indicates that the device is to be rebooted into OTA DFU mode. The rest of the OTA upgrade is managed by AppLoader and no further actions are needed from the user application.

3.8 OTA-Related Configurations in the v3.x Bluetooth Stack

Besides implementing the hook to enter DFU mode, the user application must implement some additional OTA-related configurations. These include the OTA-flag, OTA-device name, and the OTA-advertising data. For these configurations to have an effect, the OTA Software component must be installed. This can be done in Simplicity Studio 5's Project Configurator.

Note: These commands are only valid if the application contains the apploader. If the apploader is used from the bootloader, these configurations must be implemented in the bootloader.

0x02010604094F5441081B005B7728E20A68020A00: raw OTA advertising data
02: length = 2 bytes
    type = flags
    value = 6 (General Discoverable Mode, BR/EDR Not Supported)
01: length = 4 bytes
    type = complete local name
    value = OTA
08: length = 8 bytes
1B: type = BL device address
    value = 00 (public) 5B:77:28:E2:0A:68
02: length = 2 bytes
0A: type = Tx Power
    value = 0dBm

3.9 OTA-Related Configurations in the v2.x Bluetooth Stack

Besides implementing the hook to enter DFU mode, the user application must implement some additional OTA-related configurations. These include the OTA-flag, OTA-device name, and the OTA-advertising data.

static const gecko_configuration_t config = {
};
  .config_flags=0,
  .sleep.flags=SLEEP_FLAGS_DEEP_SLEEP_ENABLE,
  .bluetooth.max_connections=MAX_CONNECTIONS,
  .bluetooth.heap=bluetooth_stack_heap,
  .bluetooth.heap_size=sizeof(bluetooth_stack_heap),
  .gattdb=&bg_gattdb_data,
  .ota.flags=0,
  .ota.device_name_len=3,
  .ota.device_name_ptr="OTA",
#ifdef FEATURE_PTI_SUPPORT
  .pti = &ptiInit,
#endif

typedef struct
{
  uint32_t flags;
  uint8_t device_name_len;
  char *device_name_ptr;
}gecko_ota_config_t;

0x02010604094F5441081B005B7728E20A68020A00: raw OTA advertising data
02: length = 2 bytes
    type = flags
    value = 6 (General Discoverable Mode, BR/EDR Not Supported)
01: length = 4 bytes
    type = complete local name
    value = OTA
08: length = 8 bytes
1B: type = BL device address
    value = 00 (public) 5B:77:28:E2:0A:68
02: length = 2 bytes
0A: type = Tx Power
    value = 0dBm

3.10 Application Properties in OTA Mode

Before v3.3.x

The source file application_properties.c needs to be included in projects that use OTA and the Gecko Bootloader. This file is included in the SDK examples by default. Application properties are stored in a fixed location in code flash so that AppLoader can access the data when the device is running in OTA mode. The properties include a 32-bit version number that is application-specific. It is up to the application designer to decide how this value is encoded. This value is exposed in the GATT database used by AppLoader so that the OTA client can read it over the Bluetooth connection after the device has been rebooted into OTA mode.

The version information is set using the following #define in application_properties.c:

/// Version number for this application (uint32_t)
#define APP_PROPERTIES_VERSION 1

The default value is set to 1, but it is strongly recommended that meaningful version number information is added here so that the OTA client can check the exact version that is installed on the target device. This allows better management of OTA updates of units that are deployed in the field, especially in cases where units are running different versions of the application. If AppLoader does not detect any valid application at all, then the application version in the GATT database is initialized to value zero.

Note: Earlier SDK versions required that header file aat.h must be included by the user application. Beginning with SDK v2.7.0, this file is no longer needed, and it must not be included.

From v3.3.x and higher

From SDK version v3.3, the source file application_properties.c can be found in the folder: "...\platform\bootloader\app_properties".

3.11 Creating OTA Upgrade Images

Building a C-based Bluetooth application in Simplicity Studio does not generate the OTA DFU upgrade images (GBL files) automatically. 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)

The GBL files can be generated by invoking the script from the project directory.

If you are using Gecko SDK Suite v3.x or higher, you need to define two environmental variables, PATH_SCMD and PATH_GCCARM, before running the script as shown in the following table.

Running the create_bl_files script creates six GBL files in a subfolder named output_gbl. The files named application.gbl and apploader.gbl are used for OTA DFU. The file full.gbl is related to UART DFU upgrade and can be ignored.

If signing and/or encryption keys (named app-sign-key.pem, app-encrypt-key.txt) are present in the same directory, then the script also creates secure variants of the GBL files.

If a bootloader image (named bootloader-second-stage.s37) is present in the same directory, then the script also creates a GBL file containing bootloader+apploader images. This GBL file can be used to upgrade the bootloader.

3.12 OTA DFU Host Example

The Bluetooth SDK includes an OTA host reference implementation. The example is written in C language and uses a Bluetooth development kit as a modem in Network Co-Processor (NCP) mode. The OTA host application itself runs on the host computer. For more information on the NCP mode of operation, see QSG169: Bluetooth® v3.x Quick Start Guide or QSG139: Bluetooth® v2.x Quick Start Guide.

The following figure shows an overview of an OTA test setup. The OTA host application is running on a laptop that is connected to one Bluetooth development kit. These two together form the OTA client. The host program uses the development kit in NCP mode and communicates with it via a virtual serial port connection using the BGAPI protocol.

The target device to be upgraded over-the-air is shown on the right-hand side. It is identified by its Bluetooth address.

C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth\example_host\bt_host_ota_dfu

C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth\example_host\ota_dfu

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth\example_ncp_host\ota_dfu

./bt_host_ota_dfu.exe -u COM49 -b 115200 apploader.gbl 00:0B:57:0B:49:23
./bt_host_ota_dfu.exe -u COM49 -b 115200 application.gbl 00:0B:57:0B:49:23

3.13 OTA Error Codes

When a new GBL file is being uploaded, the AppLoader performs various checks on it. AppLoader can signal possible errors to the OTA client in two ways:

1. Response to the OTA termination code (0x03) that is written to the OTA control characteristic.
2. Response to writes to the OTA_data characteristic.

Option 2) is not available if the client uses unacknowledged writes. In that case, the possible error code is not available until the entire file has been uploaded and the client finishes the upload by writing to the OTA control characteristic.

The OTA client must always check the response value to the last write to the OTA control characteristic. Any non-zero value indicates that the update was not successful. In that case, the device is not able to boot into the main program but rather stays in OTA mode. This makes it possible to try the update again.

The following table summarizes the possible result codes returned by AppLoader.

(1) Only in SDK v3.x or later.

Note: That the error codes listed above are applicable only when testing with the NCP host example. The upper half of the result code (0x04**) is generated by the BLE stack running on the NCP host device. The size of the ATT error code that is transmitted over the air is one octet. Values in the range 0x80-0x9F are reserved for application-specific errors in the Bluetooth specification.

4. Working with AppLoader and Secure Boot

When employing secure boot, the AppLoader and application must be signed individually for the application to be allowed to run. This is because the AppLoader authenticates the application before allowing it to run, just as the bootloader authenticates the AppLoader before allowing it to run.

This section describes how to work with this capability in a production environment.

5. Implementing Device Firmware Update in the User Application

In addition to the basic UART and OTA DFU solutions discussed in previous chapters, it is possible to implement the firmware update functionality completely in the user application. This makes it possible to use a custom GATT service instead of the Silicon Labs OTA service. In case of UART DFU updates, the application can be designed to support some other protocol than BGAPI. The user application can be designed to support both OTA and UART DFU updates if needed, and it is possible to support other interfaces such as SPI.

To use this update mechanism, any application bootloader configuration may be used, using internal or external storage. At least one download area must be defined, and the area must be large enough to fit the full GBL file. Partial update is not supported. The download area must not overlap with the user application, and therefore this DFU solution is not applicable to devices or modules based on the EFR32xG1 (see Figure 3.1 Examples of Main Flash Layout when Using Gecko Bootloader with Bluetooth OTA DFU on page 6).

\gecko_sdk_suite\<version>\platform\bootloader\api\

#include "btl_interface.h"
#include "btl_interface_storage.h"

"${StudioSdkPath}/platform/bootloader"
"${StudioSdkPath}/platform/bootloader/api"