Firmware Upgrade Over the Air using BLE
Firmware upgrade during device lifetime is an essential requirement for most of applications to guarantee the performance and to keep the device updated with recent features with highest security level. Updating the firmware can be done using physical links such as USB, UART or I2C but it requires a physical connection. It is possible to update the device firmware in real time using wireless connection which is called Firmware upgrade Over the Air ( FUOTA). FUOTA using Bluetooth low Energy (BLE) protocol discussed in this article.
1. FUOTA using BLE introduction
Update procedure can be done as client/server architecture. It is initiated by an external BLE client which sends the application firmware to the device and the device acts as the server. Main software components required for BLE — FUOTA are as follows
- Softdevice ( Bluetooth stack )
- Application firmware
- Bootloader
Let’s consider each sector in detail.
1.1. Soft device
Softdevice is the encapsulation of Bluetooth stack. This should be stored in the memory in order to carry out BLE activities. Softdevice and the bootloader doesn’t change during FUOTA updates. Therefore, they do not need to be combined before sending over the air.
1.2. Application firmware
This is the main user application. During FUOTA update, application firmware send through BLE to the target device and previous application firmware is updated.
1.3. Bootloader
Bootloader or the OTA application is the part of firmware responsible for initiating, controlling and terminating the FUOTA process. Should be programmed into the head of the memory and doesn’t change during FUOTA update. Once the OTA request is received, the application jumps into the bootloader section and device is ready to receive the new application firmware. After receiving, device resets and new application firmware running on the device.
2. Memory architecture
Bluetooth stack, bootloader and the application firmware should be stored separately in the memory. Bluetooth stack is stored in the secure part of the memory which is not accessible for the user. The user accessible part splits into two parts to store the user application and bootloader.
During the upgrade process previous user application removed from the memory and the new application firmware received consequently in BLE packets stored in the memory. After receiving all the packets, new application firmware runs in the device after a reset.
3. BLE service and characteristics
3.1. User application — Reboot request characteristics
The user application supports specific GATT services. These services have own set of characteristics with specific values. To initiate the FUOTA process the user application should jump to bootloader section. This is done using “ Reboot request characteristics”. When the BLE client write into the reboot request characteristics user application jumps into OTA section.
Reboot request characteristics has 3 different fields to be notified by the client.
- The boot mode ( either user application restarts or jump to bootloader)
- Start address of the memory where new application to be downloaded
- Size of the memory to be deleted
3.2. Bootloader — Service and characteristics
Bootloader provides FUOTA file update service with 3 characteristics to carry out the update process
- Base address characteristic
- File upload confirmation characteristic
- OTA raw data characteristic
3.2.1. Base address characteristic
Base address characteristic use to send the address of the memory where the new application firmware should be stored. We can customize the characteristic to send the information such as stop all the upload, cancel the upload and to specify what type of application firmware ready to be downloaded ( Wireless FW, application file)
3.2.2. File upload confirmation characteristic
File upload confirmation characteristic is a short length notify type characteristic which is used to notify the client that file is successfully downloaded into the device. Only used at the end of FUOTA procedure.
3.2.3. OTA raw data characteristic
OTA raw data characteristic use to send the application firmware to the device. Size of the characteristic is relatively large and we can define the size according to the requirement. Application firmware splits into bytes with size of OTA raw data characteristic and send to the device sequentially.
4. Sequence diagram for firmware over the air
5. Modification of User application for upgradable format
To initiate the OTA process, user application should jump into OTA bootloader section. We added OTA reboot characteristics to user application. Client connect with the device to initiate OTA and should write to OTA reboot characteristics. Then the device jump into bootloader section and device is ready to receive the new firmware.
Reboot request characteristics has 3 different fields to be notified by the client
- The boot mode ( either user application restarts or jump to bootloader)
- Start address of the memory where new application to be downloaded
- Size of the memory to be deleted
Following changes should be done in the user application to make it upgradable Over the air
In the linker script start address of the memory changed.
Vector table relocation in the internal SRAM and flash should be removed.
We implemented BLE-FUOTA in STM32WB under 2 methods.
7. Implementation of OTA method 2
In the OTA method 2, when there is error during file upload previous application will run on the device. If the file upload is successful previous firmware is deleted and new firmware will run on the device. We organized the flash memory to store previous application new application and the bootloader as follows.
8. Limitations of BLE-FOTA
- Security concerns in FUOTA are not resolved in standard way. Intermediate device can connect to the device once it starts BLE advertising and control the FUOTA process.
- FUOTA requires bootloader( OTA application) installed in the device. This exploits some amount of memory.
- Error handling should be done in all scenarios which requires memory. Otherwise bootloader will run on the device
Originally published at https://www.senzmate.com.
