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.

BLE Service

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)

BLE Service
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.

file upload
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.

OTA raw

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

  • Modification of linker script

In the linker script start address of the memory changed.

  • Vector table offset register modification

Vector table relocation in the internal SRAM and flash should be removed.

We implemented BLE-FUOTA in STM32WB under 2 methods.

6. Implementation of OTA method 1

In the OTA method 1, bootloader should run on the device in case of error during firmware upgrade. Therefore, We removed the previous user application and saved new application in the flash memory once the file received to the device. When there is error, We cleared the user application section in the flash and relocate the vector table to run the bootloader. Then the user can again upload the new firmware. We tested the method 1 in STM32WB55RG p-nucleo development board and BLE sensor app. After validating We tested with handwash wristband device.

tech blog 1
tech blog 2

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.

ota method

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

Find the AIoT page that focuses on Senzmate's AI and IoT.