AN1084: Using the Gecko Bootloader with EmberZNet
This application note includes detailed information on using the Silicon Labs Gecko Bootloader with EmberZNet. It supplements the general Gecko Bootloader implementation information provi-ded in UG266: Silicon Labs Gecko Bootloader User’s Guide. If you are not familiar with the basic principles of performing a firm-ware upgrade or want more information about upgrade image files, refer to UG103.6: Bootloading Fundamentals.
KEY POINTS:
• Gecko Bootloader overview.
• Using Gecko standalone bootloaders.
• Using Gecko application bootloaders.
The Silicon Labs Gecko Bootloader is a common bootloader for all the newer MCUs and wireless MCUs from Silicon Labs. The Gecko Bootloader can be configured to perform a variety of bootload functions, from device initialization to firmware upgrades. The Gecko Bootloader uses a proprietary format for its upgrade images, called GBL (Gecko Bootloader). These images are produced with the file extension “.gbl”. Additional information on the GBL file format is provided in UG103.6: Bootloading Fundamentals.
On EFR32 Series 1 devices, the Gecko Bootloader has a two-stage design, first stage and main stage, where a minimal first stage bootloader is used to upgrade the main bootloader. The first stage bootloader only contains functionality to read from and write to fixed addresses in internal flash. To perform a main bootloader upgrade, the running main bootloader verifies the integrity and authenticity of the bootloader upgrade image file. The running main bootloader then writes the upgrade image to a fixed location in intermal flash and issues a reboot into the first stage bootloader. The first stage bootloader verifies the integrity of the main bootloader firmware upgrade image by computing a CRC32 checksum, before copying the upgrade image to the main bootloader location.
On EFR32 Series 2 devices, the Gecko bootloader consists only of the main stage bootloader. The main bootloader is upgradable through the hardware peripheral Secure Element. The Secure Element provides functionality to install an image to address 0x0 in internal flash, by copying from a configurable location in internal flash. To perform a main bootloader upgrade, the running main bootloader verifies the integrity and authenticity of the bootloader upgrade image file. The running main bootloader then writes the upgrade image to the upgrade location in flash and requests that the Secure Element installs it. On some devices, the Secure Element is also capable of verifying the authenticity of the main bootloader upgrade image against a root of trust. The Secure Element itself is upgradable using the same mechanism. More details are provided in UG266: Silicon Labs Gecko Bootloader User’s Guide.
The Gecko Bootloader can be configured to perform firmware upgrades in standalone mode (also called a standalone bootloader) or in application mode (also called an application bootloader), depending on the plugin configuration. Plugins can be enabled and configured through the Simplicity Studio IDE.
A standalone bootloader uses a communications channel to get a firmware upgrade image. NCP (network co-processor) devices always use standalone bootloaders. Standalone bootloaders perform firmware image upgrades in a single-stage process that allows the application image to be placed into flash memory, overwriting the existing application image, without the participation of the application itself. In general, the only time that the application interacts with a standalone bootloader is when it requests to reboot into the bootloader. Once the bootloader is running, it receives packets containing the firmware upgrade image by a physical connection such as UART or SPI. To function as a standalone bootloader, a plugin providing a communication interface such as UART or SPI must be configured.
An application bootloader relies on the application to acquire the firmware upgrade image. The application bootloader performs a firm-ware image upgrade by reprogramming the device’s flash with the firmware upgrade image stored in a region of flash memory referred to as the download space. The application transfers the firmware upgrade image to the download space in any way that is convenient(UART, over-the-air, and so on). The download space is either an external memory device such as an EEPROM or data flash or a section of the chip’s internal flash. The Gecko Bootloader can partition the download space into multiple storage slots, and store multiple firmware upgrade images simultaneously. To function as an application bootloader, a plugin providing a bootloader storage implementation has to be configured.
This document describes how to use both models with EmberZNet.
|
|
|
|
Application note & Design Guide |
|
|
|
|
Please see the document for details |
|
|
|
|
|
|
|
|
|
|
|
English Chinese Chinese and English Japanese |
|
|
|
|
|
Rev. 0.5 |
|
|
AN1084 |
|
|
592 KB |
- +1 Like
- Add to Favorites
Recommend
All reproduced articles on this site are for the purpose of conveying more information and clearly indicate the source. If media or individuals who do not want to be reproduced can contact us, which will be deleted.
Integrated Circuits
Discrete Components
Connectors & Structural Components
Assembly UnitModules & Accessories
Power Supplies & Power Modules
Electronic Materials
Instrumentation & Test Kit
Electrical Tools & Materials
Mechatronics
Processing & Customization
