Uploading Firmware Images Using OTA DFU
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)
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.
OTA DFU Sequence Implemented in Apploader
Apploader uses the the following procedure to upload images:
App is running.
Device is reset into DFU mode.
In this mode the bootloader starts the Apploader instead of the Application.
The Apploader advertises and waits for a Bluetooth connection.
The Apploader waits for the OTA start command (using OTA control characteristic).
The Apploader starts receiving the GBL file (using OTA data characteristic).
The headers of the GBL file are stored in Slot 0 to be parsed.
The Apploader uses the API of the Gecko Bootloader to parse the GBL file.
After parsing the headers, the rest of the GBL file is decoded on-the-fly and the application is copied right to the application area, overwriting the old application. Again, the Apploader uses the API of the bootloader for decoding and copying.
The Apploader receives the OTA end command and restarts the device in normal mode.
OTA DFU Sequence Implemented in User Application
It is up to the developer to decide how to upload a firmware image into the Bootloader Slot. It is however strongly recommended to use the same OTA service and procedure that is used by the Apploader, making the two process compatible. Therefore when implementing OTA DFU in the User Application it is recommended to follow this procedure:
App is running (device is not reset because the uploader is implemented in the user application).
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).
The uploader waits for the OTA start command (using OTA control characteristic).
The uploader starts receiving the GBL file (using OTA data characteristic).
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).
The uploader receives the OTA end command.
If there are multiple slots, the remote device may upload a new image to the other slot(s).
The remote device chooses which slot to bootload from using a custom characteristic.
The device is reset in bootloader mode, using the bootloader API.
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.
The bootloader starts the new Application.
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:
Connect to the target device.
Reboot the target device into DFU mode if needed.
Upload the new firmware, packaged into a GBL file.
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.