The OpenBLT 1.15.0 release was made last Monday, after another half year of development work. 21 tickets were processed, which resulted in 52 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 detail what you can expect from the new OpenBLT release.

“More ports” describes this new OpenBLT release the best. A few highlights:

• Developed a new port for the Infineon AURIX TriCore TC3 family.
• Developed a new port for the ST STM32L0 family.
• Developed a new port for the ST STM32L1 family.

Infineon AURIX TriCore TC3 family support

A couple of months ago, Infineon’s Ecosystem Manager reached out. They noticed that their customers often look for a non-AUTOSAR bootloader solution to run on their AURIX TriCore TC3 microcontrollers. With that in mind we discussed options for adding AURIX TriCore TC3 support to the OpenBLT bootloader.

After getting my hands on an AURIX TC375 Lite kit, I started working on the port development. Working with this microcontroller family for the first time, involved a bit of a learning curve. Luckily, Infineon supported me whenever I got stuck on something. The AURIX TriCore TC3 is a multi-core microcontroller, which was new for me, with many safety features, such as a large amount of CPU traps to make sure you’re not doing anything you shouldn’t be doing. Once I got that under control, the only tricky part from a bootloader perspective, was that the actual flash erase/write/verify code of the flash driver needed to run from RAM.

The OpenBLT version 1.15.0 release includes the newly developed port for the AURIX TriCore TC3 microcontroller family, together with a demo bootloader and user program for the AURIX TC375 Lite kit:

You can find getting started documentation for these demo programs on the Wiki. The same Wiki offers a page describing AURIX TriCore TC3 port specifics. Basically an overview with the changes you need to make to your own firmware, such that it can be programmed with the help of the OpenBLT bootloader.

ST STM32L0 and ST STM32L1 family support

A few years back, ST donated a bunch of STM32 Nucleo boards to the OpenBLT project. I can’t stress enough how awesome these boards are. Convenient to use, thanks to the on-board debugger and easy pin access. These boards form a perfect foundation for system prototyping purposes and even low volume production runs. For the OpenBLT bootloader, they are great because I can use these Nucleo boards for bootloader integration purposes for customers. Basically as a reference platform for which I create the customer specific bootloader packages. Gone are the days where customers need to lend me their entire development systems.

For some reason, I had two boards sitting in the closet that I never touched so far: The Nucleo-L073RZ and the Nucleo-L152RE:

Given the challenge of the microcontroller chip shortages that we’re all dealing with right now, I noticed that several customers actively look for fallback options. Allowing them to switch to a different microcontroller in their PCB design, just in case they run into sourcing problem. With this in mind, I figured it’s a smart idea to support as many STM32 microcontroller famillies as possible in the OpenBLT bootloader. Giving users a wide choice of options. Rolling with that idea, I decided that it’s about time that I develop ports for the STM32L0 and STM32L1 microcontroller families, including demo programs for these two Nucleo boards.

The OpenBLT version 1.15.0 release includes these newly developed ports for the STM32L0 and STM32L1 microcontroller families, together with demo bootloaders and user programs for the before mentioned Nucleo boards. Links to the Wiki:

• Getting started documentation for the Nucleo-L073RZ
• Getting started documentation for the Nucleo-L152RE

Website localization

Although not directly related to the actual OpenBLT version 1.15 release, the Feaser website now offers more language options. In addition to English, the website is available in the following languages:

• French
• Italian
• German
• Spanish
• Traditional Chinese

To change the language, simply go to the home page and click on the language of your preference:

Region exclusion for the firmware encryption add-on

Besides the development of new ports and demo programs, the development effort of the past half year included the usual little improvement and maintenance tasks. I’d like to highlight one of these: The firmware encryption add-on module now supports a feature, allowing to you exclude a specific memory region.

Firmware encryption add-on

The firmware encryption add-on module includes a PC command-line tool to encrypt the data inside your firmware file. You can automatically run it as a post-build step, every time you build your software. During a firmware update the bootloader then decrypts the data, right before it writes the data to flash memory. Benefits of this add-on module:

• Third parties won’t be able to program unwanted firmware on your product through the bootloader.
• Third parties won’t be able to reverse engineer your firmware, if they get their hands on the firmware file or snoop the communication line during a firmware update.

Memory region exclusion

After discussing possible improvements to the firmware add-on module with a few users, it became clear that it is a desired feature to be able to exclude a specific memory region from encryption. Users often add a so-called firmware header table at a fixed address to their firmware. It contains information such as the firmware version, but also the product type. With a quick and simple modification to the PC firmware update tools (MicroBoot and BootCommander), you can then read out the product type and firmware version of the currently programmed firmware. Next, read out the same information from the to-be-programmed firmware file. Then evaluate this information to see if the firmware update should actually be allowed or not. That way you can prevent the wrong firmware from being programmed onto your product.

What does this have to do with the firmware encryption add-on module? Well, you can’t read out this so-called firmware header table from the firmware file, if its data is encrypted. To support this use case, I developed a feature in the firmware encryption add-on, allowing you to exclude a specific memory region from encryption and decryption. For example the region reserved for the before mentioned firmware header table.

Note that the firmware encryption add-on module is a commercial add-on and not directly included in the source code of the OpenBLT version 1.15.0 release. If you previously purchased the firmware encryption add-on module and would like to use this feature, feel free to contact us for options to upgrade your previously delivered bootloader package.

Closing thoughts

After more than a decade of working on the OpenBLT bootloader, I still tremendously enjoy working on it and with it. It’s fun brainstorming together with customers to find a creative solution for their bootloader needs. The popularity of the OpenBLT bootloader continuously grows and I wholeheartedly would like to thank all customers that support the OpenBLT bootloader project by purchasing the OpenBLT commercial license. Thanks to you the OpenBLT bootloader is an actively maintained and consistently improved project, with a bright future.

Work on the next version already started. There will definitely be new ports, most likely including the Infineon AURIX TriCore TC2, possibly even the ST STM32U5. I’m also testing out some ideas for even better throughput performance during the firmware updates.