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

“Support for firmware updates via CAN FD” best summarizes the new OpenBLT release. This article provides detailed information of what you can expect from the newly released OpenBLT version 1.21.0.

Before getting into the details of the newly developed CAN FD support, I’ll first highlight a few other new features and improvements. Namely, drag-and-drop support in MicroBoot and single flash bank mode support for the STM32G4 port.

Drag-and-drop support in MicroBoot

As the title states, the MicroBoot PC tool for performing firmware updates now includes drag-and-drop support. Simply drag the firmware file on to the MicroBoot user interface and drop it. The firmware update starts automatically:

This newly developed feature works on both Windows and Linux operating systems. Drag-and-drop is especially convenient when making frequent firmware updates during development of your firmware. In this use case, consider activating the Stay open after the firmware update setting as well:

You can then keep both MicroBoot and your file explorer windows open and quickly drag your firmware file to MicroBoot to perform a firmware update.

Single flash bank mode support for ST STM32G4

Certain microcontrollers in the STM32G4 microcontroller family feature a dual bank flash device. Other STM32 microcontrollers embed a similar flash device and in general it is something that works fine with the OpenBLT bootloader.

On a side note, keep in mind that the vanilla OpenBLT bootloader does not support A/B type firmware updates, where you would need such a dual bank flash device for bank swapping. You can customize the bootloader to support this, if you really need to. I am personally not convinced that the minimal benefits of A/B type firmware updates outweigh the added complexity, ROM footprint, and the need to sacrifice 50% of your flash memory.

The OpenBLT bootloader essentially treats dual bank flash memory as if it is just one large single bank. That works fine because both banks are normally exactly adjacent to one another in the memory map.

However, the dual bank flash device on the STM32G4 has something quirky: The first bank starts at 0x08000000 in the memory map, as expected for an STM32. Yet, the second bank always starts at 0x08040000. Not an issue if you have 512kb of flash (0x40000) because then both banks are still adjacent to one another. The problem starts if you have less that 512kb flash, because then a gap shows up in the memory map between both flash banks:

This means that you have to use some linker segment magic to manually spilt your firmware over both flash banks, to be able to use its full storage capacity. Note that this is not a bootloader issue. You need to do this whether or not you use a bootloader.

To bypass this inconvenience of having to spilt your firmware over both flash banks, the flash driver of the STM32G4 was improved to also support single bank mode. In this case both flash banks are exactly adjacent again in the memory map. The only requirement from your side is that you need to enable single bank mode in the option bytes. For example with the STM32CubeProgrammer tool:

You now have one large bank starting at 0x08000000. The OpenBLT bootloader’s flash driver of the STM32G4 port automatically detects this switch, so no further changes are needed in the bootloader.

You can find this information on the STM32G4 port specifics page of the OpenBLT wiki as well, for future reference.

Support for firmware updates via CAN FD

Over the past years several users requested support for making firmware updates using CAN FD in the OpenBLT bootloader. The two major benefits of CAN FD over CAN Classic being that:

• It supports up to 64 data bytes in a CAN message, as opposed to just 8.
• It support a higher baudrate when communicating the data bytes part of the message. The so called Bit-Rate Switch (BRS).

I am proud to report that the OpenBLT 1.21.0 release includes CAN FD support. I’ll admit that it was a lot more work than anticipated, but I am quite happy with the results. A huge throughput improvement compared to CAN Classic. More about that later.

Preparation

Before being able to actually start developing this support, all my PC USB-CAN adapters needed an upgrade to support CAN FD. Luckily, the prominent CAN companies came through and sponsored the OpenBLT project with new tools. I want to specifically thank:

• Kvaser for donating a Kvaser Leaf v3.
• HMS Networks for donating an IXXAT USB-to-CAN FD.
• Peak System for donating a PCAN-USB FD.

Then I was lucky enough to find a used Vector VN1610 for an attractive price, rounding up my PC CAN hardware upgrades.

Next was the microcontroller side. I realized that most of my microcontroller boards that feature a CAN FD peripheral, don’t actually come with a CAN FD transceiver. To remedy this limitation, I designed a simple shield for STM32 Nucleo boards with a CAN FD transceiver:

Configure the bootloader for CAN FD

When developing CAN FD support in the OpenBLT bootloader, my goal was to make it easy to configure. On the microcontroller side, a typical configuration for CAN Classic looks like this in the bootloader’s configuration header-file blt_conf.h:

/** \brief Enable/disable CAN transport layer. */
#define BOOT_COM_CAN_ENABLE             (1)
/** \brief Configure the desired CAN baudrate. */
#define BOOT_COM_CAN_BAUDRATE           (500000)
/** \brief Configure CAN message ID target->host. */
#define BOOT_COM_CAN_TX_MSG_ID          (0x7E1 /*| 0x80000000*/)
/** \brief Configure CAN message ID host->target. */
#define BOOT_COM_CAN_RX_MSG_ID          (0x667 /*| 0x80000000*/)
/** \brief Select the desired CAN peripheral as a zero based index. */
#define BOOT_COM_CAN_CHANNEL_INDEX      (0)

To upgrade this to use CAN FD instead, all you have to do is add the following line:

/** \brief Configure CAN classic (0) or CAN FD (1). */
#define BOOT_COM_CAN_FD_ENABLE          (1)

The bootloader now uses CAN FD messages with up to 64 bytes. This by itself already results in the biggest throughput performance improvement. You can optionally also enable the bitrate switch feature, which then increases the baudrate when communicating the data bytes of the CAN message. For example:

/** \brief Configure the CAN FD data baudrate for the bitrate switch.  */
#define BOOT_COM_CAN_FD_BRS_BAUDRATE    (2000000)

Selecting CAN FD in the PC tools

On the PC side make sure you connected a supported CAN FD capable CAN adapter:

• For Windows 10/11, any CAN FD capable Kvaser, Peak System, IXXAT or Vector CAN adapter is supported.
• For Linux, any CAN FD capable CAN adapter that works with the kernel’s SocketCAN subsystem is supported. For example those from Kvaser and Peak System.

When using MicroBoot to initiate firmware updates, simply select the CAN FD baudrate from the combo box:

When using the BootCommander command line tool, add the -bd=[value] parameter. Example for CAN FD at 500 kb/s baudrate for both the nominal and data baudrates:

• BootCommander -t=xcp_can -d=kvaser_canlib -b=500000 -bd=500000 firmware.srec

To enable the bitrate switch and use 2 Mb/s for the data baudrate:

• BootCommander -t=xcp_can -d=kvaser_canlib -b=500000 -bd=2000000 firmware.srec

Configure CAN FD with SocketCAN under Linux

When using a CAN FD capable PC adapter with the Linux kernel’s SocketCAN subsystem, you need to first bring it online. I created a canfd.sh bash script to assist me with this. I’ll paste it here for your (and my own) reference:

#!/bin/bash
# Make sure the script runs with super user priviliges.
[ "$UID" -eq 0 ] || exec sudo bash "$0" "$@"
# Load the kernel modules.
modprobe can
modprobe can_raw
# Take the CAN interface offline.
ip link set down can0
# Set MTU to 72 to configure as CAN FD
ip link set can0 mtu 72
# Configure the CAN interface.
ip link set can0 type can bitrate 500000 sample-point 0.75 dbitrate 2000000 dsample-point 0.8 fd on restart-ms 100
# Bring the CAN interface online.
ip link set up can0

It configures your CAN FD adapter for communicating at 500 kb/s nominal baudrate and 2 Mb/s data baudrate. Feel free to adjust of course.

Performance of firmware updates via CAN FD

As promised earlier, I’ll present some performance number of comparing firmware updates via CAN Classic versus CAN FD. I used an IXXAT USB-to-CAN FD adapter on my Windows 11 PC. On the other end of the CAN bus sits a Nucleo-G431RB board running the OpenBLT bootloader. For the performance test, I created a firmware file with exactly 100kb of firmware data. The results:

It’s interesting to see that by just using 64 bytes in one CAN message versus just 8 bytes, at the exact same baudrate, more than doubles the throughput. This is because CAN message reception in user space on a PC is not so run-time efficient. With 64 bytes per CAN message, the PC application needs to receive about eight times less CAN messages, which creates this improvement.

Port and demo programs with CAN FD support

The following ports and demo programs, included with the download package of the OpenBLT 1.21.0 release, feature support for CAN FD:

• ST STM32G0 port
  • Nucleo-G0B1RE demo programs
• ST STM32G4 port
  • Nucleo-G431RB demo programs
  • Nucleo-G474RE demo programs
• ST STM32H7 port
  • Nucleo-H743ZI demo programs
• ST STM32U5 port
  • Nucleo-U575ZI demo programs
• ST STM32L5 port
  • Nucleo-L552ZE demo programs
• ST STM32H5
  • Nucleo-H563ZI demo programs

Refer to the demo program pages on the OpenBLT Wiki for details on how to get these demo programs running:

Current limitations

At this point the bootloader implements CAN FD support for all the included STM32 ports, which feature a CAN FD peripheral. The other ports (Infineon Tricore TC2/TC3 and NXP S32K11/S32K14) will follow in the near future or on demand.

While testing, I was able to get stable communication up to data baudrates of 4 Mb/s. Higher data baudrates resulted in error frames. I expect this has to do with my hardware setup, so I am curious to find out if others can get up to higher data baudrates, such as 5 Mb/s and 8 Mb/s.

Closing thoughts

It’s been almost 15 years since the first public release of the OpenBLT bootloader and it’s been quite the adventure. Initially developed as a hobby project on the side, all the way to a stable bootloader solution widely accepted by a multitude of industries.

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 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.

I cherish all the relationships I built up with the users over the years and look forward to start working towards the next stable release of the OpenBLT bootloader.