OpenBLT version 1.6.0 was officially released yesterday, after another half year of development work. 42 tickets were processed, which resulted in 140 commits. Feel free to download the new version of the OpenBLT bootloader and give it a try. This release is on track with the standard release cycle. This article describes in more details what you can expect from the new OpenBLT release.
The three main focus points for this release were: (1) A complete rework of the MicroBoot download utility, such that it is cross-platform and utilizes the OpenBLT host library (LibOpenBLT) under the hood. (2) Upgrading the STM32 ports and demo programs from the Standard Peripheral Library (SPL) to the Hardware Abstraction Layer (HAL). (3) Developing Python bindings for LibOpenBLT.
Cross-platform MicroBoot
Starting 2017 I noticed an increased interest from developers that either use Linux as their development platform and/or have a Linux machine for handling firmware updates on their microcontroller based product. This led to the decision to develop cross-platform support in OpenBLT’s PC tools.
The first step for this cross-platform support was the development of the OpenBLT host library (LibOpenBLT) and the new BootCommander command-line program. BootCommander enables you to make firmware updates from the command-line and is built on top of the LibOpenBLT functionality. It was made available in the previous release (1.5.0) of the bootloader, which was made early January this year.
After releasing the (still limited) cross-platform support for the first time, interest from Linux developers jumped from < 10% to over 15%, tendency growing. Reason enough to fully complete the cross-platform support by reworking the MicroBoot program, such that it works under Linux as well and has LibOpenBLT under the hood. MicroBoot offers a graphical user interface and offers similar functionality as BootCommander.
Something that took me a long time to commit to, was deciding on which cross-platform development environment to pick. After doing a thorough analysis where I identified the IDE selection criteria and prioritized them, it became clear that the Lazarus IDE is the best fit. After several weeks of enjoyable coding sessions in Object Pascal, we now have a fully functional and cross-platform MicroBoot. It was tested under Windows and all major Linux distributions. It even runs on a Raspberry PI, demonstrating that LibOpenBLT and BootCommander/MicroBoot are fit for embedded Linux systems as well.
Python bindings for LibOpenBLT
Python is one of the fastest-growing major programming language. This makes it likely that developers want to build their own firmware update tool in Python, built upon the LibOpenBLT functionality.
LibOpenBLT is simply put nothing more than a shared library. So a dynamic link library (DLL) under Windows and a shared object (SO) under Linux. Functionality in a shared library can be accessed from Python, by means of its ctypes library. This works great, but can be a bit overwhelming at first if you haven’t worked with this library in the past.
For this reason I decided to develop an easy to install Python package that implements a Pythonic wrapper for accessing LibOpenBLT’s shared library. You can find the installation instructions and a simple example in the readme of the Python package. A blog article is planned for the near future with more in-depth information on getting started with LibOpenBLT’s Python bindings. For now, here is a code snippet that demonstrates how the BltVersionGetString()function of LibOpenBLT is accessed:
import openblt
print('LibOpenBLT version:', openblt.version_get_string())
Upgrade STM32 to HAL
The STM32 ports of the OpenBLT bootloader build upon the peripheral software drivers provided by ST. Initially ST made these software drivers available as the Standard Peripheral Library (SPL). Over the past years ST switched to their newer Hardware Abstraction Layer (HAL). Although the SPL is still available, it is no longer actively developed and not made available for newly released STM32 microcontroller families, such as the STM32L4/F7/H7.
Several users and clients that I performed bootloader integrations and customizations for, requested an upgrade from SPL to HAL. Initially, I was hesitant and didn’t see any reason to fix something that isn’t broken. After researching a bit more and discussing this topic with my contact at ST, it is clear to me that this is the way forward.
The HAL software internally features a so called Lower Layer (LL) that resembles the SPL. I opted to use these LL drivers as much as possible to keep the ROM footprint of the bootloader small. Nonetheless, the ROM footprint did grow a bit as a side effect of the upgrade from SPL to HAL. Overall about 10 to 20%.
In this new 1.6.0 release of the bootloader, the following STM32 ports, including all related demo programs, were upgraded from SPL to HAL already: STM32F0/F2/F3/L4. The STM32F1/F4 ports and demo programs are still based on SPL and are planned to be upgraded to HAL over the next half year.
Firmware readout protection
With the rise of IoT devices, the topic of security becomes more and more important. Developers want to lock down their microcontroller based product as much as possible. The OpenBLT bootloader itself, combined with a few add-on modules, already offers a very secure solution.
One of these security features is the seed/key protection. It is available in the OpenBLT bootloader by default and can be enabled through a configuration macro in “blt_conf.h”. Once enabled, an unauthorized user cannot reprogram the flash memory through the bootloader. For authorization, the bootloader’s programming resource must first be unlocked with a key. The algorithm for generating this key is located in a shared library and accessed by the firmware update tool (MicroBoot/BootCommander). The best part is that you can implement this key generation algorithm any way you like.
The seed/key protection works great. However, it only protects against erase and programming operations of the microcontroller’s flash memory. It did not protect against reading out memory contents. Communication between the firmware update tool and the bootloader is based on the standardized XCP communication protocol. This one by default allows memory read operations. The implementation of the XCP module was changed in this newly released version of the OpenBLT bootloader. When the seed/key protection feature is enabled, memory readouts now always return a 0 value for all bytes, unless the programming resources is successfully unlocked with an authorized key.
Newly supported ports and development boards
This release of the OpenBLT bootloader supports the following new microcontroller family:
Additionally, demo programs for the following development boards were added:
Furthermore, an Atollic TrueStudio version is now available for all STM32 related demo programs.
Personally, I am very satisfied with all the new features and improvements in the this new version of the bootloader. Planning for the next version is already in progress. Feel free to contact me with your wishlist of functionality that you would like to see in a future version of the OpenBLT bootloader.
