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

“Improved USB support and flash erase performance” describes this new OpenBLT release the best. A few highlights:

• Automatic USB driver installation.
• USB serial number configuration.
• More ports with USB support.
• Faster flash erase operation.

Automatic USB driver installation

To perform firmware updates via USB, the OpenBLT PC tools make use of Window’s WinUSB functionality. WinUSB is basically a generic USB driver provided by Microsoft and available since Windows Vista.

Even though the generic WinUSB driver (winusb.sys) is already available in Windows, it was still necessary to install a USB driver through the Zadig tool. This step was needed to link a so-called unique Device Interface GUID to the USB device’s vendor and product identifiers (VID/PID). Afterwards, the PC tools can identify and talk with the USB device, simply by specifying this Device Interface GUID.

Ever since Windows 8, it is actually possible to automatically install the WinUSB driver. All OpenBLT demo programs configured for firmware updates via USB, now support this automatic WinUSB driver install. No more fiddling around with the Zadig tool. Just connect your microcontroller board, running the OpenBLT bootloader, to the USB port of your Windows PC and everything is ready to go. This makes firmware updates via USB true plug-and-play.

It was quite a challenge to put together all the puzzle pieces to get this working. I’m really happy with the results, as it makes performing firmware updates via USB so much more user friendly.

Under the hood

Making this automatic WinUSB driver installation work, essentially meant that the Device Interface GUID had to be embedded into the bootloader firmware, such that Windows can detect and extract it during the USB enumeration.

For those interested in doing something similar for their WinUSB device, here’s a brief overview of how it works:

• Set bcdUSB to a value greater than 2.00 in the device descriptor. I used 2.01. This triggers Windows to request a Binary Device Store (BOS) descriptor during enumeration.
• Upon request of the BOS descriptor, return the Microsoft OS 2.0 platform capability descriptor. This triggers Windows to request a Microsoft OS 2.0 descriptor set during the setup stage.
• Upon request of the Microsoft OS 2.0 descriptor set, return one with the WinUSB Device Interface GUID registry property.
• As a result, Windows will link the specified Device Interface GUID to the USB device’s VID/PID. Just like what you previously had to do manually with the Zadig tool.

You can look at the OpenBLT demo programs for code examples. The Nucleo-F429ZI demos implements this for the ST USB stack. Look for the macro USBD_WINUSB_ENABLED in the demo bootloader’s source code. If you prefer to use the TinyUSB stack instead, refer to the XMC4700 Relax Kit demos and look for the macro CFG_TUD_WINUSB_ENABLED.

USB serial number configuration

Each USB device should have a unique serial number. That way your PC can identify between devices with the same VID/PID. From a bootloader perspective and firmware updates via USB, this was not that critical. Simply because it’s unlikely that you attached multiple USB devices, running the OpenBLT bootloader.

Nevertheless, I went through the effort to report the microcontroller’s unique identifier, when the USB host requests the serial number during enumeration. You can look for examples in demo bootloaders configured for firmware updates via USB. The only demo bootloader that does not support this, is the TI DK-TM4C123G board. But that’s because the TM4C123G microcontroller does not feature unique identifier.

More ports with USB support

While working on improving the USB support in the OpenBLT bootloader, I also added USB drivers to these ports:

• ST STM32F2
• Infineon XMC4

There are still a few ports that do not yet include a USB driver. For example the STM32F0, STM32G0 and STM32G4. That’s simply because I currently do not have a development board that brings out the USB device. In general, if you need USB support and it is not yet present in the microcontroller port that you intend to use, I’ll happily develop it on demand.

Faster flash erase operation

When performing the flash erase operation, the PC tools request the erasure of memory chunks up to 32kb in size. The sector erase sizes on most microcontrollers are typically in the 1kb to 32kb range. So that works out just fine. However, for microcontrollers with a sector erase size of more than 32kb, this consequently meant that the flash erase operation ran multiple times, unnecessarily.

Take fore example a microcontroller with a minimal flash erase sector size of 64kb. When the PC tool requests the erasure of 32kb, it will in fact erase the full 64kb. That’s expected and by design. However, when the PC tool requests the erase of the next adjacent 32kb, it will yet again erase the same full 64kb, even though it is already in the fully erased state. Also not a major problem, but it does waste run-time overhead. By adding flash empty checks, I was able to bypass this unnecessary run-time overhead.

On some ports, the erase time did not change much. However, on other ports this improvement yielded significant reduction in the flash erase time. Here are some test results from doing a full chip erase on these boards:

• XMC4700 Relax Kit: 88% faster.
• Olimex STM32-P207: 72% faster.
• Olimex STM32-P405: 77% faster.
• Nucleo-F746ZG: 82% faster.
• Nucleo-H743ZI: 79% faster.

Especially if you use one of these ports, I can recommend upgrading to the new OpenBLT version 1.16. Note that if you currently have an active support and maintenance contract, you can contact me and request an upgrade of your previously delivered bootloader package, to the latest stable release.

Demo programs and ports

With this new release the following additions and changes were made to the ports and demo programs:

New ports

• STM32U5

New demo programs

• Nucleo-U575ZI – Configured for RS232, CAN and USB firmware updates.
• Nucleo-F207ZG – Configured for RS232, TCP/IP and USB firmware updates.
• Nucleo-G431RB – Configured for RS232 and CAN firmware updates.
• Olimexino STM32F3 – Configured for RS232, CAN, USB and SD-card firmware updates.

Changed demo programs

• Nucleo-F103RB – Added support for CAN firmware updates.
• STM32F3-Discovery – Better pull-up resistor management on the USB-D+ line.
• XMC4700 Relax Kit – Added support for USB firmware updates (using TinyUSB).
• XMC1400 Boot Kit – Use the external crystal to clock the CAN peripheral for better accuracy.

Closing thoughts

Making a full-time living from an open-source product is definitely fun and exciting. Yet it can also be a bit nerve-racking at times. Especially at the start of the year, I catch myself wondering: “Will it work out again this year?” Somehow it always does. At least the past decade or so. This year also started strong.

Thanks to everyone who purchased the OpenBLT commercial license, the OpenBLT bootloader project is thriving. The funds generated by the OpenBLT commercial license sales, make it possible for Feaser to continue sponsoring OpenBLT development and maintenance.

Work on the next version already started. The planning might change a bit over the next months, based on requests and feedback from the user base. However, this is what I am currently planning to focus on:

• Add Modbus-RTU as a new communication interface. If you are interested in this, you might also be interested in Feaser’s new MicroTBX-Modbus software component.
• An events module. Think callbacks that can be used for progress and error reporting. This makes it possible to show firmware update progress on a display or to log it somewhere. Especially handy for performing firmware updates from an SD-card.
• Possible new ports: ST STM32H5, ST STM32C0 and Infineon AURIX TriCore TC2.