The OpenBLT 1.22.0 release was made today, after another half year of development work. 35 tickets were processed, which resulted in 85 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.

“It’s a big one!” best summarizes the new OpenBLT release. This article provides detailed information of what you can expect from the newly released OpenBLT version 1.22.0.

Before getting into the newly added features, let’s start of with an overview of the performed maintenance tasks:

• Prevented potential Y2K38 problems in the PC tools under Linux.
• Upgraded the HAL drivers in all the STM32 demos.
• Upgraded all demos that build with GCC to GNU ARM Embedded version 13.3.
• Upgraded all demos that build with the IAR Embedded Workbench to version 9.70.1
• Upgraded all demos that build with the Keil MDK to use the V6 compiler.
• Upgraded all demos that use the S32 Design Studio to version 3.6.3.

Support for CMake

Based on reports from the OpenBLT user base, more and more developers prefer CMake as the build system for their embedded firmware. I’m a fan of using CMake myself as well and already use it in the OpenBLT PC tools where applicable. For example: LibOpenBLT and BootCommander.

With that fact in mind, it was about time that I added a CMakeLists.txt to OpenBLT bootloader. It’s included in this new OpenBLT version 1.22.0 release. You can find it in the \Target\Source\ directory. This makes it quick and easy to perform a bootloader integration:

• Setup a new CMake project for your development board.
• Add the subdirectory, where you located the OpenBLT bootloader’s target sources, to your project’s CMakeLists.txt:

add_subdirectory(third_party/openblt)

• Add the OpenBLT core, port and compiler specific libraries. Example for the STM32F4:

target_link_libraries(MyBootloader
    openblt-core
    openblt-armcm4-stm32f4
    openblt-armcm4-stm32f4-gcc
)  

• Copy and configure the blt_conf.h and hooks.c files from the template demo bootloader.
• Call BootInit() before entering your infinite program loop in main(), and call BootTask() continuously inside your infinite program loop.
• Done!

For more detailed information, refer to the comment block at the start of the OpenBLT bootloader’s CMakeLists.txt file. For an example project that uses CMake for building the bootloader, look at the Infineon XMC4700 Relax Kit demo bootloader.

EU Cyber Resilience Act

Probably most, if not all, embedded software developers came in contact with the EU Cyber Resilience Act (CRA) in some shape or form in the past year. It adds security related responsibilities to companies, who plan on selling their microcontroller based products on the European market. Part of this responsibility lands in the hands of the embedded software developers.

In a nutshell, the CRA requires you to report a security related vulnerability, the moment it becomes known that someone or something managed to exploit it. Then within a reasonable period of time, you need to make available a security patched firmware for your product.

Most embedded firmware depends on other third party software components. This means that you also become responsible for scanning for potential security related issues of these components, because it might result in security related vulnerabilities for your product. This is where the Software Bill of Material (SBOM) comes into play. The SBOM is a machine-readable inventory of all the software dependencies in your product’s firmware. Think of it as a map that shows you what is in your product’s firmware. The SBOM enables you to perform automatic vulnerability scanning.

Starting with OpenBLT release 1.22.0, Feaser includes the bootloader’s SBOM in every stable release. You’ll find it in the release’s ZIP-archive that you can download from the SourceForge page. You can find OpenBLT’s Software Bill of Materials at this location in the ZIP-archive:

• \Doc\openblt.spdx.json

The fact that the CRA requires you to make available security patched firmware, implies that your product features a bootloader. Several users contacted Feaser to ask: Is the OpenBLT bootloader suitable for this purpose? We are currently working closely together with a handful of customers to definitively answer this question and to see how Feaser can assist in the process. Implementing the five levels of security as explained in this blog article, gets you really far already. Additionally, consider signing up for the OpenBLT annual support and maintenance contract. Customers with an active support and maintenance contract automatically get informed of critical bugfixes (including security related ones) and they can request their previously delivered bootloader package to be updated accordingly.

Events Module

The biggest new feature in the OpenBLT release 1.22.0 is the Events Module. The events module emits event signals during a firmware update. For example when memory is being erased and programmed, when the firmware update completes, or in case an error occurred.

Why would you want to use this? A couple or reasons:

• To display firmware update progress on a display. Especially handy for firmware updates from a locally attached FAT file system, such as an SD-card.
• To log event related information. For example using Segger’s RTT or written to a log-file on an SD-card.
• To update a table to keep track of which software version was installed and when (EU Cyber Resilience Act requirement).

Each time the bootloader emits an event signal, it calls the EventsHook() function in your bootloader and passed on the event identifier and details as parameters. To enable the events module, add the following line to your bootloader’s blt_conf.h configuration header-file:

/** \brief Enable/disable the events module. */
#define BOOT_EVENTS_ENABLE              (1)

Next, implement the EventsHook() function in your hooks.c source-file. You can find a self-explanatory example for this in the demo bootloader template.

For additional reference, the following demo bootloaders enabled the event module:

• ST STM32F723-Discovery – It shows firmware update related information on the TFT display.
• Olimexino-STM32F3 – It writes firmware update related information to a log-file on an SD-card.
• Infineon XMC4700 Relax Kit – It logs firmware update related information using Segger’s RTT.

TinyUSB

Over the years I definitely see an uptick in requests for firmware updates using USB. The OpenBLT bootloader already fully supports this. It implements a USB Device that embeds the bootloader’s XCP communication protocol packets in USB Bulk transfers. The best part of it is that is’ll fully plug-and-play on both Windows and Linux. No need to manually driver installation.

Most customers use the OpenBLT bootloader on STM32 microcontrollers. For those ports, the USB Device functionality built upon ST’s Middleware USB device component. However, ST seems to be switching to the USBX stack, which is currently tightly coupled to the ThreadX RTOS. This is a bit of a problem, because I don’t think an RTOS has any place in a bootloader. Not only should a bootloader have a small ROM footprint, it should also have the least amount of complexity. Simply because complexity increases the chance of bugs and a bootloader tends to get flashed once during product assembly, and typically runs for the lifetime of the product. So now what?

In comes TinyUSB. A well-maintained open-source USB Host and Device stack, specifically for microcontrollers. Due to its cross-platform nature and supports for all the microcontroller families that the OpenBLT also supports, it’s a perfect fit. It was a bit of an effort, but the OpenBLT bootloader now fully switched to the TinyUSB stack for firmware updates via USB.

New ports with USB support

After intensively working with TinyUSB, I fell more and more in love with this USB stack. It’s so easy get up-and-running on new microcontrollers. Consequently, I added support for firmware updates via USB to more OpenBLT ports:

• ST STM32C0
• ST STM32F0
• ST STM32G0
• ST STM32G4

Experimenting with USB Host

After working with TinyUSB to create the OpenBLT USB Bulk device, it left me wondering: Wouldn’t it be possible to use TinyUSB to develop some sort of solution for firmware updates via USB Host? Going through my entire inventory of microcontroller development boards, I found the ST STM32F723-Discovery board. It exposes a USB Host connector. Perfect!

Long story short, I managed to create a bootloader for the ST STM32F723-Discovery board with TinyUSB integrated, configured to act as a USB Host Mass Storage Class (MSC). What does this mean? Well, you can plug-in a USB memory stick with a FAT file system, and you can they access the entire FAT file system, through the FatFS library. The bootloader already supported firmware updates from a FAT file system, through the FatFS library. Combining the two, makes it possible to simply copy your firmware file to a USB memory stick. Next, plug the USB memory stick into the ST STM32F723-Discovery board to make the firmware update.

And because the ST STM32F723-Discovery board also features a TFT display, I enabled the new Events Module and implemented EventsHook() such that the display shows the firmware update progress:

Since this works so well, I decided to include the ST STM32F723-Discovery board OpenBLT demo programs in the OpenBLT 1.22.0 release. Details on getting these demo programs up-and-running are on the Wiki.

Experimenting with a USB Composite Device

At this point I wondered: What more fun stuff can I do with TinyUSB in combination with the OpenBLT bootloader? I remembered that I received the occasional question from users, if the OpenBLT bootloader supports firmware updates via the standardized USB Device Firmware Upgrade (DFU) class. At the same time I had a shiny new Nucleo-C071RB board sitting on my desk, which features a USB Device connector, and for which I planned on creating OpenBLT demo programs. It wasn’t long before I managed to get firmware updates via USB DFU working. With the freely available dfu-util tool, you can make firmware updates via DFU.

Something that I was always curious about was: How does one develop a USB Composite Device? Essentially a USB Device that shows up as multiple entries in the Windows Device Manager. To summarize: I was able to use the Nucleo-C071RB board to build a demo bootloader that shows up as three USB devices:

• USB Device Firmware Upgrade (DFU)
• USB Device Mass Storage Class (MSU)
• USB Communication Device Class (CDC)

More importantly, you can actually perform a firmware update using all these USB device classes! Because this worked quite well, I decided to add the resulting Nucleo-C071RB OpenBLT demo programs to the OpenBLT 1.22.0 release. You can find additional details on the Wiki.

Custom XCP communication interface

As regular users of the OpenBLT bootloader probably know, the bootloader makes use of the XCP communication protocol under the hood, for firmware updates. I was exposed to the XCP communication early on in my career. Back then is was still called CAN Calibration Protocol (CCP). The change from CCP to XCP simply meant that the communication protocol is no longer just for CAN. It can be used on virtually any communication interface and physical layer. I gratefully embraced this improvement, making it currently possible in the bootloader to perform firmware updates via:

• RS232
• CAN (FD)
• USB
• TCP/IP
• Modbus-RTU

From time-to-time I get a request for a different type of communication interface. I’ve done bootloader customizations to work with proprietary RS485 communication packets for example. Every time I work on such a customization, I end up having to make a few changes in the low-level core of the bootloader, to get this all working. To improve on this, I developed support for enabling and implementing a custom XCP communication interface to the bootloader’s core.

How does it work? In essence you add few configuration macros to your blt_conf.h header file to enable this feature and to configure the size of the communication packets:

/** \brief Enable/disable custom transport layer. */
#define BOOT_COM_CUSTOM_ENABLE           (1)
/** \brief Set the maximum XCP packet size that the transport layer can transmit. */
#define BOOT_COM_CUSTOM_TX_MAX_DATA      (63)
/** \brief Set the maximum XCP packet size that the transport layer can receive. */
#define BOOT_COM_CUSTOM_RX_MAX_DATA      (63)

Next, you implement the functions ComCustomInitHook(), ComCustomFreeHook(), ComCustomReceivePacketHook(), and ComCustomTransmitPacketHook() for your specific communication interface.

To further demonstrate how you would implement these hook-functions, I reworked the STM32F3-Discovery board demo programs. The demo bootloader now uses TinyUSB to create a USB Communication Device Class (CDC) device. Essentially making it a Virtual COM port, such that you can perform firmware updates by simply selecting RS232 in the MicroBoot and BootCommander PC tools. A custom XCP communication interface had to be created, because the bootloader’s standard RS232 driver works, by directly accessing the microcontroller’s UART peripheral. therefore, making it work with the USB CDC device instead, would mean a rewrite of the RS232 driver in the bootloader’s port. Instead of changing any code in the bootloader, a custom XCP communication interface was implemented to realize this functionality.

New PC tool option to bypass firmware starting

When you perform a firmware update with either MicroBoot or BootCommander, the newly programmed firmware automatically starts, once the firmware update successfully completes. A few users requested a way to override this behavior. They preferred a workflow where the bootloader stays running after the firmware update. For example if you have your firmware split over two firmware files. One for the program logic and one with calibration or configuration parameters. You don’t want the bootloader to start the newly programmed firmware, until after the data of the second firmware file was programmed as well.

This is now supported. In MicroBoot you can check the checkbox labeled “Keep the bootloader running after the firmware update”:

In BootCommander, you can add the -ns command-line parameter:

Closing thoughts

Personally, I am very proud of and satisfied with this OpenBLT release 1.22.0. The Events Module was something I wanted to develop for a long time now, just never got around to doing it. It was a big task and I wasn’t able to block out enough time to make it happen in the past. Development of the Events Module got a higher priority, because of the EU Cyber Resilience Act. Following the CRA guidelines, there should be a way to keep a history log of all previously made firmware updates: What firmware version got installed and, ideally, when? For this there needs to be some sort of “Firmware update successfully completed” event that you can hook into. So I decided, now is the time to work on the Events Module.

I reorganized my work a bit to make available more time for OpenBLT development and maintenance tasks. This meant that I outsourced more bootloader customization and portation work to my small team of experienced and trusted contractors. This worked out great as you can see in these release notes. Not only does the bootloader now have the much needed Events Module, I was also able to do a lot of extra work, resulting in three times the amount of commits and issue tickets processed, compared to previous releases.

I would like to especially thank those who purchased the OpenBLT commercial license and those who keep renewing their OpenBLT annual support and maintenance contract. It is thanks to you that my modest single-person company Feaser can continue sponsoring the development and maintenance of the OpenBLT bootloader, allowing me to work full-time on the OpenBLT bootloader project. If you do not need the OpenBLT commercial license, but would still like to support my efforts, consider making a donation.