Uploading Firmware Images Using OTA DFU#

Introduction#

Gecko Bootloader can load application images into the application area from the following sources:

  • Host controller via UART/SPI

  • Internal flash (if the internal flash is big enough to accommodate both the application code and an upgrade image)

  • External flash

OTA DFU (Over-The-Air Device Firmware Upgrade) is not implemented in the Gecko Bootloader. To upload images OTA you will need a dedicated Bluetooth application. You can either use

  • Apploader. The Apploader is a simple application - separated from the main application - with a minimal Bluetooth stack that handles the upload process.

  • User application extended with the ability to upload firmware images to the flash.

The Apploader overwrites the application area directly (with help of the Bootloader). It can do so, since it runs independently from the user application.

The user application cannot overwrite itself, hence it has to place the upgrade image into a dedicated flash area (Bootloader Slot) first, and then ask the bootloader to load the image into the application area.

Sources For Uploading ImagesSources For Uploading Images

OTA DFU Sequence Implemented in Apploader#

Apploader uses the the following procedure to upload images:

  1. App is running.

    Ota Slot 1Ota Slot 1

  2. If there are multiple slots, the remote device chooses which slot to upload to, using a custom characteristic (e.g., slot0. Slot0 can be either in the internal or in the external flash. The application does not have to know this because flash is handled by the bootloader API).

  3. The uploader waits for the OTA start command (using OTA control characteristic).

  4. The uploader starts receiving the GBL file (using OTA data characteristic).

  5. The GBL file is saved into slot0/slot1 as it is using the bootloader API (the application does not have to know where Slot0/Slot1 is located because the bootloader API handles the writing).

    Ota Slot 2Ota Slot 2

  6. The uploader receives the OTA end command.

  7. If there are multiple slots, the remote device may upload a new image to the other slot(s).

  8. The remote device chooses which slot to bootload from using a custom characteristic.

  9. The device is reset in bootloader mode, using the bootloader API.

  10. The bootloader parses the given slot, retrieves the Application code from the GBLfile, and copies the code to the application area from the internal/external flash.

    Ota Slot 3Ota Slot 3

  11. The bootloader starts the new Application.

Differences#

From external viewpoint, the OTA process is almost the same whether the target application uses Apploader or handles the update in the user application code. The main steps (simplified) are:

  1. Connect to the target device.

  2. Reboot the target device into DFU mode if needed.

  3. Upload the new firmware, packaged into a GBL file.

  4. When the upload is finished, Gecko bootloader installs new firmware on top of the old version.

The main difference when compared to Apploader based OTA is that there is no separate DFU mode and step 2 in the above list is not needed at all. The GBL file is uploaded to the target device under the control of the user application.

Some of the benefits of this approach are:

  • The user application remains fully functional while the OTA image is being uploaded.

  • It is possible to implement customer specific OTA service/protocol (with application level security if needed).

  • EM2 deep sleep is supported during OTA upload.

  • BLE security features (link encryption, bonding...) can be used.

Sleep and BLE encryption/bonding are not supported by Apploader to reduce the flash footprint!

An obvious disadvantage of this solution is the requirement to have a dedicated flash space available as a download area.

Interaction between Gecko Bootloader and User Application#

Gecko Bootloader has a key part in the OTA update. After GBL file is uploaded, Gecko Bootloader takes care of parsing the GBL file and installing the new firmware. The bootloader is also needed during the OTA file upload to write the image to the proper flash area.

Gecko Bootloader has an application interface exposed through a function table in the bootloader. This means that the user application can call functions implemented in the bootloader, even though the application is running in normal mode. In other words, the bootloader API functions are called from the user application context, but the implementation is in the Gecko bootloader project. For example, the user application can call the function bootloader_writeStorage to write data into the download area without knowing where the download area is actually located.

A list of the key bootloader API calls needed to implement OTA update is in AN1086, Chapter 4.

Code Examples#