Bluetooth OTA updates are covered in detail in application note AN1086. https://www.silabs.com/documents/login/application-notes/an1086-gecko-bootloader-bluetooth.pdf
Most of the AN1086 is focusing on the default in-place OTA update process using AppLoader. As Described in Chapter 4, it is also possible to implement OTA updates in the user application. AN1086 also includes a simplified code sample to illustrate the process. This article explains in more detail how OTA can be handled by user application. An example implementation is provided as a code package that can be installed on top of the soc-empty template.
The reader is expected to be familiar with the content of application note AN1086 (especially Chapter 4).
This example is not applicable in any parts with 256kB flash (BGM111, BGM113, BGM121, BGM11S, BGMEFR32xG1 SoC) (unless external SPI flash is used as download area)
List of parts compatible with this example: BGM13P/S, MGM12P, EFR32xG12, EFR32xG13.
To use this example, your device needs to be programmed with a suitable Gecko bootloader. When creating the bootloader project, select the version named Internal Storage Bootloader (single image on 512kB/1MB device), depending on the size of internal flash in your device.
For more details on Gecko bootloader, see the user guide UG266 - https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf .
From external viewpoint, the OTA process is almost the same whether the target application uses AppLoader or handles the update in 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 here 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. In this example, the file upload is done using the Silicon Labs proprietary OTA service (as specified in AN1086), but it is possible to use also any other customer specific service and protocol to handle the file upload.
Some of the benefits of this approach are:
the user application remains fully functional while the OTA image is being uploaded
possibility to implement customer specific OTA service/protocol (with application level security if needed)
EM2 deep sleep is supported during OTA upload (*
normal 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 of course the requirement to have dedicated flash space available to be used as the download area.
Gecko bootloader has a key part in the OTA update. After GBL file is uploaded, it is Gecko bootloader that takes care of parsing the GBL file and installing the new firmware. The bootloader is also needed during the OTA file upload.
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. As a practical example, the user application can call function bootloader_writeStorage to write data into the download area, without even knowing where the download area is physically located.
A list of the key bootloader API calls needed to implement OTA update is found in AN1086, Chapter 4.
The code sample provided in AN1086 is a simplified version to fit it in one page. The full example provided here includes some additional debug prints and features like printing the estimated data transfer rate.
The main functional difference is related to the erasing of the download area. In the simplified code of AN1086, the download area is erased when the remote OTA client starts the OTA process (writing value 0 to ota_control). In this example, the download area is erased at startup. The code also reads the content of the download area and does an erase only if needed (i.e. if the download area is not already blank). The reason for this change is to avoid dropping connection due to supervision timeout. Erasing the whole download area (256k or more) will take several seconds (it is a blocking function call) and this can lead to supervision timeout unless the connection parameters are specifically adjusted to prevent it.
The attached zip file includes copy of the necessary source codes and also detailed instructions (see readme.txt) on how to install this code on top of the soc-empty template.
Remember that to use this example, you also need to program the target device with suitable Gecko bootloader variant. The application detects the download area information dynamically at runtime. If you have a suitable bootloader installed, you should see something like this printed to the debug output (tested on EFR32BG12)
Gecko bootloader version: 1.0 Slot 0 starts @ 0x00084000, size 499712 bytes
As the OTA update client, you can use the Blue Gecko mobile application. Another possibility is to use the BLED112 dongle and the update client attached to this KB article.
NOTE: you need to use the GBL file named full.gbl to run the update. The files are generated using the same script that is used for normal AppLoader based OTA (create_bl_files.bat/sh)
If your device has enough flash capacity, then you can use more than one download area. The following KB article demonstrates how to use multiple download areas and select the slot to be used dynamically via the GATT database:
Adding include paths:
right-click the project name in Simplicity Studio, then select properties.
In project properties: C(C++ build -> Settings -> GNU ARM C Compiler -> Includes
You can use the Blue Gecko app on the phone or use the ota_dfu application which comes with the SDK and is located in this path.
i mcu is efr32mg12p332f1024gL125 , i use inter flash ota，
Both of these functions return 0；
bootloader_writeStorage(0,//use slot 0
this function return 0x0402, ota_image_position initialization is 0，why ?
in my bootload project ,The start address of my configuration is 0x8400
Hi I have a couple of questions. I was able to change the project around to download the image while running the application using your example. I have a couple of questions remaining though:
1. Since I'm no longer using the AppLoader, can I remove that from the linker file (.icf) and from the project settings?
2. If I want the bootloader and application to be updateable, is it possible through this approach? Do I just download the bootloader + application gbl file and the bootloader will know it has to call the secure elements in order to update the bootloader part?
3. If 2 is possible, I should modify the linker icf file to allow more space for the download area if I want the bootloader + application to be update-able. I have a 1MB chip so I modify it so the bootloader + application use 508kB, the download area is 508kB and we need to reserve 8kB for nvm data. When I do this the bluetooth stack fails to start up. Any idea why?
1. Yes - you can remove the apploader from your linker map if you aren’t using it (i.e. you are implementing an application bootloader as discussed in section 4 of AN1086).
2. Section 3.2 of UG266 describes the process for upgrading the bootloader when using an application bootloader with storage. You are correct that you just have to download the bootloader + application GBL. The bootloader handles the rest.
3. I recommend using the internal storage bootloader (see section 6.3.5 in UG266 – Gecko Bootloader User’s Guide). The default settings for single image on a 1MB give you 499712 of storage, which is more than enough for your application + bootloader. This doesn’t require any messing with linker settings, so the only linker setting you need to modify is to remove the apploader.