The OpenBLT 1.13.0 release was made last Friday, after another half year of development work. 20 tickets were processed, which resulted in 38 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 CAN support” describes this new OpenBLT stable release the best. A few highlights:
- Support for Ixxat CAN PC interfaces from HMS Products.
- Support for CAN in the STM32G0 port.
- Resolved an issue that caused extremely slow firmware updates via CAN for certain users on Windows 10.
- Developed a new port for the ST STM32G4 microcontroller family.
- Added demo programs for the Nucleo-G474RE, Nucleo-G0B1RE and Nucleo-L496ZG boards.
Support for Ixxat CAN-USB interfaces
HMS Networks develops and produces a wide variety of high quality CAN PC interfaces under their Ixxat product line name. After getting requests for supporting these CAN PC interfaces in the OpenBLT host tools, I touched base with HMS Networks. They were very kind to donate a USB-to-CAN FD interface to the OpenBLT project.
For CAN bus analysis, HMS Networks includes their free canAnalyzer mini PC tool. An easy-to-use tool for viewing CAN messages on the bus and for sending out your own CAN messages. For developing your own PC applications, based on CAN communication with Ixxat CAN PC interfaces, they offer their VCI application programming interface. VCI stands for Virtual Communication Interface.
Based on this VCI API, I developed support for the Ixxat CAN PC interfaces in the OpenBLT host library (LibOpenBLT). Followed by a few minor tweaks to the MicroBoot and BootCommander PC tools, such that you can actually select a Ixxat CAN PC interface, for making firmware updates via CAN. Thanks to the design of their VCI API, the OpenBLT PC tools not only support the USB-to-CAN FD interface, but actually all Ixxat CAN PC interfaces:
Resolved slow firmware updates via CAN that some users reported
Starting mid 2020, I received sporadic reports from users that sometimes firmware updates via CAN were excruciatingly slow. As in it would take over half an hour to perform a firmware update. The tricky part: I could not reproduce this problem on my own PC. The only thing I knew was:
- The problem only happened under Windows 10, not under Linux.
- It seems to not happen with the Peak PCANUSB.
Together with several users and the friendly engineers over at Kvaser, we spent a large chunk of time trying to get to the root of the problem. It turns out that the root cause of the problem was a Windows 10 update. Update version 2004 to be exact, which rolled out starting April 2020. Specifically the change in the Windows API function timeBeginPeriod. You can find more details in the Remarks section in this function’s description.
In a nutshell, this function controls the minimum timer resolution for a Windows application. Prior to Windows 10 version 2004, if one application changes the timer resolution using function timeBeginPeriod, it would change it globally for all applications. After this specific Windows 10 update, it no longer affects all applications globally.
A lot of Windows applications (WPF, SQL Server, Chrome, games, etc.) find the default timer interval of 1/64 MHz = 15.625 ms too long and therefore called timeBeginPeriod to shorten the default timer interval. Before the Windows 10 version 2004 update, this would affect other application as well, including the OpenBLT PC tools.
How did this affect firmware updates via CAN? Well, a background thread handles the reception of CAN messages. If no CAN messages were available, I added a Sleep(1) call to sleep for about a millisecond. The idea was to not hog up the CPU. After the Windows 10 version 2004 update, it could happen that this sleep call now resulting in a 15.625 ms delay, instead of just 1. And that was the cause of the slow firmware updates via CAN. The solution was super simple. I just had to remove the Sleep(1) function call in LibOpenBLT’s CAN driver.
Newly supported ports and development boards
This release of the OpenBLT bootloader supports the following new microcontroller family:
Additionally, OpenBLT now features demo programs for the following development boards.
- ST Nucleo-G474RE – Configured for firmware updates via RS232 and CAN.
- ST Nucleo-G0B1RE – Configured for firmware updates via RS232 and CAN.
- ST Nucleo-L496ZG – Configured for firmware updates via RS232 and USB.
Closing thoughts
As you can read in the article Reflecting on 10 years of the OpenBLT bootloader, the OpenBLT bootloader project turned 10 years old recently. I never though that something that started out as a hobby side project would turn into something this big. I tremendously enjoy the work involved. On the one hand development and maintenance work on the code base itself and on the other hand assisting users with getting bootloaders running on their systems. Sometimes in ways I never imagined. A true testament to both the creativity of the OpenBLT users and the modularity of the code’s architecture. I look forward to all the bootloader projects coming towards Feaser in the year 2022!
