The first stage is dummy. It can only start the second stage and it can overwrite the second stage with an already uploaded upgrade image. The first stage can only be flashed to the device and cannot be upgraded!
The second stage starts the application and it is able to upgrade the application in several ways, like using UART, SPI, Bluetooth, etc. It has other features as well, like handling multiple storage slots, verifying the images, etc. Unlike the first stage, the second stage is upgradable through the same channels as the application (UART, SPI, Bluetooth, etc.)
Upgrading via UART
This part discusses how you can upgrade the second stage via UART. For this you have to use the BGAPI UART DFU type Gecko Bootloader!
If you already have the bootloader flashed, the second stage can be upgraded in 3 steps:
Upload new second stage image in the device (it will be put to a predefined address)
Reset the device -> the first stage will overwrite the second stage with the new image
Upload the application again, since some part of it may have got corrupted when the second stage image was uploaded
In practice, follow these steps to upgrade your second stage:
Create a new bootloader project you want to upgrade to
Bootloader can only be upgraded and not downgraded, hence you need an increased version number with every upgrade. If you want to upload the same bootloader version with another configuration, then you have to increase BOOTLOADER_VERSION_MAIN_CUSTOMER. Find the "Other" tab in the AppBuilder of the Bootloader project (opening .isc file), and add BOOTLOADER_VERSION_MAIN_CUSTOMER to the defines. Define a value greater than 0, then increase this with every upgrade.
Generate and build your bootloader project
Create a bootloader upgrade file (.gbl) from the .s37 output file (*). E.g.
Upload the upgrade image. E.g. if the upgraded bootloader is an BGAPI UART DFU type bootloader, you can use the uart-dfu application (**) to do this:
uart-dfu COMn 115200 application.gbl
Now your bootloader is upgraded and your application is restored.
Note:
(*) commander.exe can be found under
C:\SiliconLabs\SimplicityStudio\vX\developer\adapter_packs\commander
(**) uart-dfu.exe can be found under
C:\SiliconLabs\SimplicityStudio\vX\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth_<version>\examples_ncp_host\uart_dfu\exe
after make was run in
C:\SiliconLabs\SimplicityStudio\vX\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth_<version>\examples_ncp_host\uart_dfu\
Upgrading OTA (over-the-air)
This part discusses how you can upgrade the second stage via Bluetooth connection (OTA – over the air). For this you have to use a Bluetooth in-place OTA DFU type Gecko Bootloader, and you have to upgrade to stack version 2.7 or later (If you already have an older stack version running on the device, it is not a problem, but upgrade is necessary.)
If you already has the bootloader flashed, the second stage can be upgraded in 4 steps:
Upload new second stage image along with an apploader image. Note: this will overwrite the current application image.
Reset the device -> the first stage will upgrade the second stage with the new bootloader image. Note: this process will overwrite some part of the current apploader image.
Reset the device -> the second stage will upgrade the corrupted apploader image with the newly uploaded apploader image.
Upload the application image again. This will upgrade the corrupted application image.
In practice, follow these steps to upgrade your second stage:
Bootloader can only be upgraded and not downgraded, hence you need an increased version number with every upgrade. If you want to upload the same bootloader version with another configuration, then you have to increase BOOTLOADER_VERSION_MAIN_CUSTOMER. Find the "Other" tab in the AppBuilder of the Bootloader project (opening .isc file), and add BOOTLOADER_VERSION_MAIN_CUSTOMER to the definitions. Define a value greater than 0, then increase this with every upgrade.
Generate and build your bootloader project
Open your Bluetooth application project or create a new one (SDK v2.7 or later)
Build your project if you haven’t done so yet
Copy the second stage bootloader image bootloader-storage-internal-ble.s37 (the .s37 file that does not end with –combined.s37) from your Bootloader project into your Bluetooth application project
Find the following line in create_bl_files.bat (which can be found in the Bluetooth project):
Repeat this for signed and encrypted images if you use signed/encrypted images
Run the create_bl_files.bat file, which creates the GBL files in the output_gbl folder
Do a full OTA update on your devices the same way as you do a full OTA for upgrading the stack/apploader and application, but now use these two files:
apploader+bootloader.gbl
application.gbl
During the OTA process the device resets itself twice, so there is no need for user interaction. After the OTA update, your bootloader is updated. You can check its version in the system_boot event of the Bluetooth stack or in the Gecko Bootloader version characteristic of the Silicon Labs OTA service (see AN1086)
I am testing the Gecko bootloader on EFR32 platform. I have a scenario in which i need to upgrade with a bootloader hving same version number or lesser version number. than the currently flashed one.
In this guide it is mentioned that 'Bootloader can only be upgraded and not downgraded'. Is it possible by remove this limitation by a code change. If yes can you provide some hint on which file i should do the needed changes.
0
Hi,
Unfortunately, the limitation is in the first stage of the bootloader, which is not provided as source code, hence you cannot change it.
To downgrade the bootloader you have to re-flash it.
0
Hi
Thanks for the information arkalvac. Is there any plan to make the source code first stage bootloader available in any upcoming GA release.
0
There is no plan for this currently.
What you can do is replacing the version number (BOOTLOADER_VERSION_MAIN_CUSTOMER) of the older version with a higher one.
0
Hi
Bootloader version number change is not a feasible solution in our implementation. What we are looking for is keep both BLE and zigbee stack/bootloaders in the host and switch the firmware between zigbee/BLE as per user requirement. Ideally we will be having 2 firmwares whose version numbers are fixed.
0
Hi,
I see your point. Indeed, this switching is currently impossible. However, it is not really needed at all. You can switch between stacks without switching bootloader. This might be a bit unusual for the first time, but we are heading in the direction of having only one protocol to communicate with the bootloader. So I encourage you to choose one protocol and use it both with BLE and ZigBee stack. What kind of bootloader configurations are you using for BLE and for ZigBee?
0
Hi
Our device is a gateway and running in NCP mode. I was using BGAPI UART DFU type bootloader for BLE application upgradation and UART XMODEM Bootloader for upgrading Zigbee application.
I have seen a Multiprotocol demo video of EFR32MG12 running Zigbee/BLE stacks in SoC mode. Our requirement is running Zigbee/BLE applications in a single NCP chipset and during startup, select any one stack to boot as per user configuration on host side(via some commands from host over UART). Our host is running Linux and the image upgrade of stack images will be through UART interface only(We dont plan for any OTA upgrade as ours is an NCP implementation) where linux should have control on upgrading correct image to the correct slot of internal flash.
Can you provide some suggestion on Gecko bootloader protocols which will fit best for our requirements and some guidelines on implementing this.
0
Hi,
In this case you really do not need to switch bootloader. You can upload both BLE and ZigBee images either with XMODEM or with BGAPI. The bootloader protocol is independent of the application protocol. So choose either XMODEM or BGAPI (which you prefer) and upload both images with that bootloader. You have to switch protocol on the host side only when the application is running.
The only thing you have to be aware: host application does 2 steps:
1) reset the device in DFU mode
2) send data to the bootloader
If you use a Bluetooth application and an XMODEM bootloader, you have to reset the device with the BGAPI command, and send the data via XMODEM. So you have to modify the default host application provided with the SDK.
0
Hi Arkalvac
I am able to upgrade ble/zigbee firmwares by XMODEM and BGAPI protocol. We are going to implement this olin our product. In your previous message you mentioned that you are heading in tthe direction to have a single protocol to talk to the bootloader. May i know which will be future proof out of XMODEM and BGAPI.
0
Hi,
There is no decison upon this yet. I would suggest using XMODEM for now, it is a more widely used standard.
KBA_BT_0605: Upgrading Gecko Bootloader
Gecko bootloader consists of two stages.
Upgrading via UART
This part discusses how you can upgrade the second stage via UART. For this you have to use the BGAPI UART DFU type Gecko Bootloader!
As a first step you should flash both the first and the second stage of the bootloader to your device. To flash the first + second stage bootloader with a Bluetooth application, follow the steps detailed in http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/Adding-Gecko-Bootloader-to-Bluetooth-projects/ta-p/195432
If you already have the bootloader flashed, the second stage can be upgraded in 3 steps:
In practice, follow these steps to upgrade your second stage:
Upload the upgrade image. E.g. if the upgraded bootloader is an BGAPI UART DFU type bootloader, you can use the uart-dfu application (**) to do this:
Note:
(*) commander.exe can be found under
C:\SiliconLabs\SimplicityStudio\vX\developer\adapter_packs\commander
(**) uart-dfu.exe can be found under
C:\SiliconLabs\SimplicityStudio\vX\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth_<version>\examples_ncp_host\uart_dfu\exe
after make was run in
C:\SiliconLabs\SimplicityStudio\vX\developer\sdks\gecko_sdk_suite\<version>\app\bluetooth_<version>\examples_ncp_host\uart_dfu\
Upgrading OTA (over-the-air)
This part discusses how you can upgrade the second stage via Bluetooth connection (OTA – over the air). For this you have to use a Bluetooth in-place OTA DFU type Gecko Bootloader, and you have to upgrade to stack version 2.7 or later (If you already have an older stack version running on the device, it is not a problem, but upgrade is necessary.)
As a first step you should flash both the first and the second stage of the bootloader to your device. To flash the first + second stage bootloader with a Bluetooth application, follow the steps detailed in http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/Adding-Gecko-Bootloader-to-Bluetooth-projects/ta-p/195432
If you already has the bootloader flashed, the second stage can be upgraded in 4 steps:
In practice, follow these steps to upgrade your second stage:
During the OTA process the device resets itself twice, so there is no need for user interaction. After the OTA update, your bootloader is updated. You can check its version in the system_boot event of the Bluetooth stack or in the Gecko Bootloader version characteristic of the Silicon Labs OTA service (see AN1086)
For more information please refer to UG266: Gecko Bootloader User Guide
Hi
I am testing the Gecko bootloader on EFR32 platform. I have a scenario in which i need to upgrade with a bootloader hving same version number or lesser version number. than the currently flashed one.
In this guide it is mentioned that 'Bootloader can only be upgraded and not downgraded'. Is it possible by remove this limitation by a code change. If yes can you provide some hint on which file i should do the needed changes.
Hi,
Unfortunately, the limitation is in the first stage of the bootloader, which is not provided as source code, hence you cannot change it.
To downgrade the bootloader you have to re-flash it.
Hi
Thanks for the information arkalvac. Is there any plan to make the source code first stage bootloader available in any upcoming GA release.
There is no plan for this currently.
What you can do is replacing the version number (BOOTLOADER_VERSION_MAIN_CUSTOMER) of the older version with a higher one.
Hi
Bootloader version number change is not a feasible solution in our implementation. What we are looking for is keep both BLE and zigbee stack/bootloaders in the host and switch the firmware between zigbee/BLE as per user requirement. Ideally we will be having 2 firmwares whose version numbers are fixed.
Hi,
I see your point. Indeed, this switching is currently impossible. However, it is not really needed at all. You can switch between stacks without switching bootloader. This might be a bit unusual for the first time, but we are heading in the direction of having only one protocol to communicate with the bootloader. So I encourage you to choose one protocol and use it both with BLE and ZigBee stack. What kind of bootloader configurations are you using for BLE and for ZigBee?
Hi
Our device is a gateway and running in NCP mode. I was using BGAPI UART DFU type bootloader for BLE application upgradation and UART XMODEM Bootloader for upgrading Zigbee application.
I have seen a Multiprotocol demo video of EFR32MG12 running Zigbee/BLE stacks in SoC mode. Our requirement is running Zigbee/BLE applications in a single NCP chipset and during startup, select any one stack to boot as per user configuration on host side(via some commands from host over UART). Our host is running Linux and the image upgrade of stack images will be through UART interface only(We dont plan for any OTA upgrade as ours is an NCP implementation) where linux should have control on upgrading correct image to the correct slot of internal flash.
Can you provide some suggestion on Gecko bootloader protocols which will fit best for our requirements and some guidelines on implementing this.
Hi,
In this case you really do not need to switch bootloader. You can upload both BLE and ZigBee images either with XMODEM or with BGAPI. The bootloader protocol is independent of the application protocol. So choose either XMODEM or BGAPI (which you prefer) and upload both images with that bootloader. You have to switch protocol on the host side only when the application is running.
The only thing you have to be aware: host application does 2 steps:
1) reset the device in DFU mode
2) send data to the bootloader
If you use a Bluetooth application and an XMODEM bootloader, you have to reset the device with the BGAPI command, and send the data via XMODEM. So you have to modify the default host application provided with the SDK.
I am able to upgrade ble/zigbee firmwares by XMODEM and BGAPI protocol. We are going to implement this olin our product. In your previous message you mentioned that you are heading in tthe direction to have a single protocol to talk to the bootloader. May i know which will be future proof out of XMODEM and BGAPI.
Hi,
There is no decison upon this yet. I would suggest using XMODEM for now, it is a more widely used standard.