Introducing the LibMicroBLT library

The OpenBLT bootloader just got even better. Last week saw the release of the OpenBLT embedded library, or LibMicroBLT in short. The LibMicroBLT library contains all the functionality for performing a firmware update on another connected microcontroller, running the OpenBLT bootloader. Think of LibMicroBLT as a microcontroller optimized version of the OpenBLT host library (LibOpenBLT). The following picture illustrates in what type of system architecture you could use LibMicroBLT:

Illustration showing the architecture of a system, featuriing a main controller that integrates LibMicroBLT.

The LibMicroBLT library assumes that your main controller can access a file system for storing firmware files. This can be an SD card, USB stick or flash memory chip. Internally, LibMicroBLT relies on the FatFs software component for accessing the file system. So as long as you can make your file storage medium work with FatFs, you’re good to go.

You can freely choose how the firmware files end up on the file system. LibMicroBLT just reads them, when instructed to perform a firmware update. Some ideas:

  • You manually copy the firmware file(s) to the SD card from your PC. Afterwards you insert the SD card into your main controller.
  • Your main controller periodically checks for and downloads new firmware files from an FTP server, network drive or cloud storage (S3 bucket, Dropbox, Google Drive, OneDrive, etc).

LibMicroBLT is written in the C programming language (C99) with MISRA compliance in mind. Thanks to its permissive MIT license, you are free to integrate and distribute the library in your commercial closed source firmware.

Multi node system

For simplicity, the system architecture shown in the previous illustration shows just one connected node. However, combined with OpenBLT’s Master/Slave Gateway add-on module, you can create all sorts of complex multi node systems. For example:

Example system architecture that is possible with the LibMicroBLT library, in combination with the OpenBLT master/slave gateway add-on module.

The main controller, running LibMicroBLT, could perform firmware updates on all attached nodes. In this system architecture, you would just need to integrate the Master/Slave Gateway add-on module with the OpenBLT bootloaders on Node A1 and Node B1.

Firmware update procedure

The following flowchart explains which LibMicroBLT API functions to call, to perform a the firmware update on one or more connected microcontrollers:

Flowchart visualizing the firmware update procedure and specfically which functioon of the LibMicroBLT library to call.

You can find a fully working and reusable function, which implement this procedure, in the included demo application. It’s function UpdateFirmware(), located in:

  • demos/ARMCM4_STM32F4_Olimex_STM32P405_CubeIDE/App/update.c

Library architecture

The following image illustrates the modular architecture of LibMicroBLT and how it fits into your firmware:

Modular architecture of the LibMicroBLT library.

Firmware typically consist of:

  • HAL – Hardware Abstraction Layer. For accessing low-level microcontroller peripherals.
  • OS – Operating System. Either the good ol’ super loop or a real-time operating system (RTOS).
  • APP – Your actual application.

The LibMicroBLT library sits between your application and the hardware abstraction layer. That way your own application can call its functions for performing a firmware update on another microcontroller, which runs the OpenBLT bootloader.

LibMicroBLT itself depends on two third-party libraries:

  • FatFs for file system access to read the actual firmware files.
  • MicroTBX for assertions, critical sections, heap, memory pools and linked lists.

Inside LibMicroBLT, you’ll find three modules:

  • Firmware module – The firmware module embeds all the functionality for reading the firmware file and extracting firmware data from it.
  • Session module – The session module implements all the functionality for communicating with the OpenBLT bootloader running the other microcontroller(s).
  • Port module – The port module makes it possible to connect your hardware specifics to the hardware independent LibMicroBLT library.

Porting to your hardware

The port module inside the LibMicroBLT library interfaces with some hardware specifics, for example to access a timer and communication peripheral(s). The idea is that you implement port functions in your own firmware. Then link them to LibMicroBLT by calling the library’s API function BltPortInit() , during your firmware initialization.

You can find a fully functional version of these port functions in the demo application. It assumes CAN communication between LibMicroBLT and the other microcontroller, which runs the OpenBLT bootloader. The demo application is located in this directory:

  • demos/ARMCM4_STM32F4_Olimex_STM32P405_CubeIDE/

If you selected a different communication transport layer for firmware updates (RS232, Modbus RTU, etc.), you can look at the OpenBLT code base on the XCP packets format that the bootloader expects.

Getting started

In contrast to LibOpenBLT, the OpenBLT download package does not directly include LibMicroBLT. GitHub hosts the LibMicroBLT library in a separate GIT repository:

To get started with using LibMicroBLT, you can download the latest stable release from the releases page. Next, read through the getting started documentation in the online user manual, which you can find here:

Alternatively, you can clone the latest development version directly from GitHub. Just make sure to update the submodules after cloning, because LibMicroBLT makes use of a few submodules:

git clone
git submodule update --init
This entry was posted in OpenBLT and tagged , . Bookmark the permalink.