OpenBLT 1.18.0 release notes

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

Roadmap for the OpenBLT version 1.18.0 release.

“Mostly maintenance and a few new features” best summarizes the new OpenBLT release. This article provides detailed information of what you can expect from the newly released OpenBLT version 1.18.0.

New STM32H5 port with Nucleo-H563ZI demos

Did you check out ST’s STM32H5 microcontroller family already? Versatile, high performance, good security options and most of all: competitively priced. I expect the STM32H5 will turn out to be a popular microcontroller family over the next decade and beyond. A logical upgrade for those that are currently using an STM32F3/F4.

OpenBLT version 1.18 is the first release to include full support for the STM32H5 microcontroller family. To get started with the bootloader on this microcontroller family, you can find demo programs for the Nucleo-H563ZI board. The demo bootloader supports firmware updates via RS232, CAN, USB and TCP/IP.

While developing USB support for this port, I decided to not use the ST USB device stack and switch to TinyUSB instead. ST seems to move from their own ST USB device stack to UsbX, which is the one bundled with the ThreadX RTOS. Although I am not necessarily against that, it just doesn’t fit a bootloader. UsbX depends on a full blown ThreadX RTOS and I don’t think adding an RTOS is the way to go for the bootloader. For personal projects I worked with TinyUSB and like it. For this reason I decided to give it a try and it turns out it works quite well in the OpenBLT bootloader. I might even consider making it the standard USB stack for those ports and demo programs that support firmware updates via USB in the near future.

New features in MicroBoot and BootCommander

The majority of OpenBLT user perform a firmware upgrade on one microcontroller system. They start MicroBoot, select the firmware file, firmware update process runs and once done, MicroBoot automatically closes. A smooth workflow.

However, what if you need to perform multiple firmware updates after one another? For example in a system with multiple nodes, a master/slave system, or if you have a separate firmware file for calibration and configuration parameters. In this use case it gets tedious if you need to keep on reopening the MicroBoot program.

For this reason you can now configure MicroBoot to stay open after the firmware update. This enables you to start a new firmware update right away. You can find this new configuration option on the Miscellaneous-tab of the settings dialog:

MicroBoot settings dialog screenshot, highlighting the new configuration option to keep the MicroBoot program open once the firmware update finished.

BootCommander doesn’t need this feature. It’s a command-line program, which you can easily run multiple times from a Shell or Batch script. BootCommander did get a small new feature though. It now outputs the version of the underlying LibOpenBLT library:

Screenshot of the BootCommander output during a firmware update, highlighting that it now outputs information about the LibOpenBLT library version it uses.

Note that MicroBoot’s log-file already includes the same information, in case you would like to see the LibOpenBLT version there as well.

Upgraded HAL drivers of all STM32 demos

ST continuously improves the HAL (and LL) drivers of their Cube software solution. The bootloader gratefully builds upon the HAL drivers in the STM32 ports and demo programs. Periodically I go through the effort of upgrading all the HAL drivers in the STM32 demo programs to their latest stable release, while also performing a run-time test to make sure all still works as expected. A bit of a boring and tedious task to be honest, but one I find important to make sure everything still builds and runs as expected.

While working on this, I also upgraded all the STM32CubeIDE projects to use the newer version 1.15. The included GCC ARM embedded compiler requires a few changes to the linker script. In case you run into build warnings or errors, while trying out an OpenBLT demo program, make sure to upgrade your STM32CubeIDE to at least version 1.15.

Improved STM32 Ethernet support

Overall ST keeps the API of their HAL drivers stable. Every now and then they do make a breaking change unfortunately. A bit of a headache for those depending on it, such as the OpenBLT project, but I am sure they have a good reason for this. A few years ago they changed the API of the CAN driver. Not too long ago, they revamped their Ethernet drivers.

At first I was a bit bummed about this, because it means that I need to rework the network device drivers for the uIP TCP/IP stack the bootloader uses. While working on it, I can only conclude that the new Ethernet drivers are a major improvement. The API is much nicer to work with. All STM32 demo programs that support firmware updates via TCP/IP, now use the new Ethernet driver. With the exception of the demo programs for the STM32F2. The HAL drivers for the STM32F2 for some reason do not (yet?) include the new Ethernet drivers.

Talking about demo programs with support for firmware updates via TCP/IP, I finally managed to get this working on the Nucleo-H743ZI board. As some of you might now, OpenBLT did not offer TCP/IP support for the STM32H7 for the past years. Simply because I was not able to get this working. The STM32H7 is a bit of a wild beast when it comes to configuring Ethernet. While working on the Ethernet driver upgrade, I figured: Why not give this another go? I am happy to report that I finally figured out how to properly configure this. Consequently, the OpenBLT release 1.18 now includes Nucleo-H743ZI demo programs with firmware updates via TCP/IP configured and working.

Upgraded FatFS

For firmware updates from a file system, the OpenBLT bootloader relies on the FatFS library. The bootloader includes this library as a third party module. With the release of OpenBLT version 1.18, an upgrade form FatFS R0.12 to R0.15 was made.

FatFS R0.12 was working just fine in the OpenBLT bootloader. I just figured it’s a good idea to upgrade to the current stable release of FatFS. The upgrade was straightforward. The only real issue being that some of the configuration macros in “ffconf.h” were renamed. These now have a “FF” prefixed to them, e.g. “FF_FS_READONLY” instead of “_FS_READONLY”.

Extra memory driver for Nucleo-L152RE demo

A question that pops up every now and this is: Can the OpenBLT bootloader work with additional memory devices? Think for example of external serial EEPROM for storing configuration and calibration parameters or even a quad- or octo-SPI flash device for running firmware using eXecute In Place (XIP).

This is of course possible with the OpenBLT bootloader. Through hook-functions you can add support for whatever extra memory you prefer to use. However, this was not really documented very well. To improve, I decided to add an example of this to the Nucleo-L152RE demo bootloader. I selected this particular one, because the STM32L152RE microcontroller features an internal 16kb data EEPROM, in addition to its flash EEPROM. Making it the perfect candidate to showcase how to add support for such an extra memory driver.

To further document and explain this feature, I wrote an blog article about this. The blog article presents a template memory driver that you can use yourself and explains how to integrate this into your OpenBLT bootloader project.

Closing thoughts

The release of OpenBLT version 1.18 includes mostly maintenance updates and a few new features. Definitely a solid foundation and I am quite happy with the state that it’s in. Ever since its first public release in 2011, I have not had any reports of firmware update breaking problems with the bootloader from customers that use it in production. That’s quite a track record and I am committed to delivering the same type of stability for the OpenBLT bootloader in the years to come. Work for the next stable release already started.

Just a quick reminder for those with an active support and maintenance contract: It includes a free upgrade of your previously delivered commercially licensed bootloader to the latest stable release, when requested. Feel free to contact me to schedule the upgrade of your bootloader package to OpenBLT version 1.18.

This entry was posted in OpenBLT and tagged , , . Bookmark the permalink.