Silicon Labs UG235.06 User Manual
UG235.06: Bootloading and OTA with
Silicon Labs Connect v2.x
This chapter of the Connect v2.x User’s Guide explains the bootloader options (standalone, application, and Over the Air (OTA))
available for use within Connect-based applications. The Connect
v2.x User’s Guide assumes that you have already installed the
Simplicity Studio development environment and the Flex SDK,
and that you are familiar with the basics of configuring, compiling,
and flashing Connect-based applications. Refer to UG235.01: De-
veloping Code with Silicon Labs Connect v2.x for an overview of
the chapters in the Connect v2.x User’s Guide.
The Connect v2.x User’s Guide is a series of documents that provides in-depth information for developers who are using the Silicon Labs Connect Stack for their application
development. If you are new to Connect and the Proprietary Flex SDK, see QSG138:
Proprietary Flex SDK v2.x Quick Start Guide.
Proprietary is supported on all EFR32FG devices. For others, check the device's data
sheet under Ordering Information > Protocol Stack to see if Proprietary is supported. In
Proprietary SDK version 2.7.n, Connect is not supported on EFR32xG22.
KEY POINTS
• Introduces different bootloaders.
• Describes using the Gecko Bootloader.
• Describes how to set up a Silicon Labs
Connect application for bootloading.
• Describes how to use the standalone
bootloader with an SOC or NCP Host
application.
• Describes how to use the application
bootloader for OTA.
silabs.com | Building a more connected world. Rev. 0.4
UG235.06: Bootloading and OTA with Silicon Labs Connect v2.x
Introduction
1. Introduction
It is often required to update firmware on devices when it is not feasible to connect a J-Link debugger. In these cases, a standalone
bootloader is ideal because it makes it possible to update the firmware through a Universal Asynchronous Receiver/Transmitter (UART)
or Serial Peripheral Interface (SPI) connection.
In some cases, even connecting a device to a computer is problematic. In these instances, an OTA (Over the Air) bootloading process
can work. This requires an application bootloader which can update the firmware from an onboard storage (like an SPI flash memory or
part of the MCU flash memory). However, the OTA image transfer is still the responsibility of the main application.
For more details on bootloading basics, see UG103.06: Bootloading Fundamentals.
silabs.com | Building a more connected world. Rev. 0.4 | 2
UG235.06: Bootloading and OTA with Silicon Labs Connect v2.x
The Gecko Bootloader
2. The Gecko Bootloader
Silicon Labs Connect only supports the Gecko Bootloader which is available for the Wireless Gecko (EFR32™) portfolio. For the standalone bootloader, the UART XMODEM Bootloader example is recommended. For the application bootloader, either the SPI Flash Stor-
age Bootloader (if SPI flash is attached the EFR32) or the Internal Storage Bootloader applications are recommended. Note that the
OTA protocol available for Silicon Labs Connect only supports single image bootloaders.
Once you have compiled the bootloader, make sure to flash it (the <projectname\>-combined.s37 file) on your device before flashing
the main firmware.
For more details on using the Gecko Bootloader examples, see AN1085: Using the Gecko Bootloader with Silicon Labs Connect. For
more information on the Gecko Bootloader, see UG266: Silicon Labs Gecko Bootloader User’s Guide.
silabs.com | Building a more connected world. Rev. 0.4 | 3
UG235.06: Bootloading and OTA with Silicon Labs Connect v2.x
Setting Up a Silicon Labs Connect Application for Bootloading
3. Setting Up a Silicon Labs Connect Application for Bootloading
To make an application ready for bootloader usage, select either the Standalone or the Application bootloader on the HAL tab of Application Builder. This will:
• Modify the linker script on EFR32xG1 (where the first 16kB of the flash memory is used by the bootloader).
• Modify the linker script to reserve the first 4B of RAM for communication between the bootloader and the main firmware.
• Add GBL file (binary image for bootloading) generation to the build process.
• Add a compile time define that can be used by bootloader-related code.
• Add c functions that can be used to communicate with the bootloader from the main firmware (for example, to switch to bootloader
mode).
• Add the application properties data that can be read by the bootloader from a GBL image.
Some specific application features like OTA needs some plugins as well. These requirements will be discussed in the following chapters.
silabs.com | Building a more connected world. Rev. 0.4 | 4
UG235.06: Bootloading and OTA with Silicon Labs Connect v2.x
Using the Standalone Bootloader with a System on Chip Application
4. Using the Standalone Bootloader with a System on Chip Application
The standalone bootloader can be used without further modification in the application code. If you enable the GPIO activation feature in
the Gecko Bootloader (enabled by default), you can enter bootloader mode by resetting the MCU while pushing the activation button.
Then, you can communicate with the bootloader as described in AN1085: Using the Gecko Bootloader with Silicon Labs Connect.
Alternatively, you can enter bootloader mode by using the following function in your application:
halLaunchStandaloneBootloader(STANDALONE_BOOTLOADER_NORMAL_MODE)
For further details on the communication API with the bootloader, see the file
platform/base/hal/micro/bootloader-interface-standalone.h
silabs.com | Building a more connected world. Rev. 0.4 | 5
UG235.06: Bootloading and OTA with Silicon Labs Connect v2.x
Using the Standalone Bootloader with an NCP-Host Application
5. Using the Standalone Bootloader with an NCP-Host Application
The standalone bootloader can be used in NCP-host mode to update the firmware on the NCP device from the host device. To use this,
make sure standalone bootloader on your NCP device and the Bootloader NCP CLI plugin in your host application are enabled (both
are enabled by default). This will add a three CLI commands to the NCP-host:
• bootloader info – Returns information of the bootloader.
• bootloader launch – Starts the bootloader.
• bootloader load-image – Loads a firmware image using an external tool.
To use the third command:
1. Compile the host application on the host (currently only POSIX operating systems like Linux are supported). Go to the folder
named protocol/flex/ and call make -f connect/plugins/serial-bootloader/bootload-ncp-uart-app.mak
This will generate the binary bootloader-ncp-uart-app under
protocol/flex/connect/build/bootloader-ncp-uart-app/
2. Once you have this binary and the firmware image on your host machine, you can load it using the following commands (note the
use of double quotes around the string parameters):
bootloader launch
then
bootloader load-image "<path to loader>" "<path to the firmware> <offset> <size>" [other bootloader
options]
• <path to loader> is the path to bootloader-ncp-uart-app compiled in step 1.
• <path to the image> is the path to the firmware image to load.
• <offset> is the offset inside the image where loading should start (typically 0).
• <size> is the size of the image or 0xFFFFFFFF to use the whole file.
• [other bootloader options] is where further options can be passed to the bootloader-ncp-uart-app.
Note: option "-p <serial port>" is mandatory. See bootloader-ncp-uart-app -h for further details.
silabs.com | Building a more connected world. Rev. 0.4 | 6
Loading...