The OpenBLT 1.14.0 release was made last Friday, after another half year of development work. 20 tickets were processed, which resulted in 23 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.
“Shiny new things” describes this new OpenBLT release the best. A few highlights:
- Availability of LibMicroBLT, the OpenBLT Embedded Library.
- 64-bit version of the Windows PC tools.
- Automatic dependency generation in the Makefiles.
- Improved data throughput on RS232 and TCP/IP.
OpenBLT Embedded Library – LibMicroBLT
Simply put, LibMicroBLT is a microcontroller optimized version of LibOpenBLT. The LibOpenBLT library packs functionality for parsing firmware files and communicating with a microcontroller, running the OpenBLT bootloader. On Windows it is a DLL-file and on Linux a SO-file. With the help of LibOpenBLT, you can quickly and easily build your own firmware update PC tool. In fact, the included PC tools MicroBoot and BootCommander build upon the same library.
Over the years, several users asked me if they can run LibOpenBLT on a microcontroller. Theoretically you can, but it wasn’t really designed with that use case in mind. For example, the firmware parser stores the entire firmware data in dynamically allocated memory. Something that only works. if your microcontroller offers an abundance of RAM.
To better address this use case, LibMicroBLT was developed. It packs similar functionality for parsing firmware files and communicating with another microcontroller, which runs the OpenBLT bootloader. More importantly, it can run on RAM constrained microcontrollers and was architected for easy integration and porting.
Where to use it
LibMicroBLT offers the perfect solution in a multi node system, where your main controller can directly access the firmware files and is tasked with performing firmware updates on the connected nodes:
You are free to choose how the firmware files end up on the file system. A few ideas:
- Manually copied from your PC via an SD card.
- Downloaded from an FTP server or network drive.
- Downloaded from cloud storage (S3 bucket, Dropbox, Google Drive, OneDrive, etc.)
If you combine LibMicroBLT with the Master/Slave Gateway add-on module, you can perform firmware updates on a system with all sorts of different nodes and sub-nodes:
How to get it
I decided on placing LibMicroBLT in its own GIT repository. As such, it is not directly included in the download package of OpenBLT release 1.14.0. You can find the GIT repository at this URL:
LibMicroBLT is MIT licensed. This pretty much means that you can freely use it in both open source and closed source commercial firmware. For additional information refer to the online user manual:
It includes getting started information, a description of the demo application and a detailed API reference.
Default 64-bit for PC tools under Windows
Starting with OpenBLT release 1.14.0, the included PC binaries for Windows are all 64-bit and upgraded for building with the latest Visual Studio 2022. This includes MicroBoot, BootCommander and LibOpenBLT.
At this point in time, 64-bit is the default for development tools. If you create a new project in Visual Studio, it defaults to building a 64-bit executable. If you install the Python interpreter, the recommended flavor is the 64-bit one. With LibOpenBLT still being a 32-bit library, this meant that developers had to explicitly reconfigure their project to output a 32-bit executable, otherwise it couldn’t load the 32-bit LibOpenBLT library. When building a firmware update tool using Python, it even meant that the end-user needed a 32-bit Python interpreter.
These hassles are over, now that the included PC binaries are all 64-bit by default. Note that if you absolutely still need 32-bit versions of these binaries, this is still possible. The Wiki contains details on how to rebuild them as 32-bit.
The previous version of the PC binaries for Windows still relied on the external “UsbBulkLilb.dll” file, when performing firmware updates via USB. The new 64-bit version of LibOpenBLT now directly embeds this functionality. Meaning that you no longer need to distribute this extra DLL-file. In case you are curious about what the USB communication code looks like in LibOpenBLT, you can find it here:
Automatic dependency generation in GCC Makefiles
Almost all OpenBLT demo programs include a version that you can build with the popular GNU ARM Embedded toolchain. These demo programs provide a Makefile for building the demo programs. A properly configured Makefile should ideally know exactly what header-files a specific source-file depends on. That way the Makefile can determine which source-files need to be compiled, after making a change in a header-file.
I took a little shortcut there. I simple listed all header-files as a dependency for each source-file. That means that a simple change in just one header-file, resulted in a re-compilation of all source-files. Even if a source-file didn’t include it, either directly or indirectly. Not a major issue, but also not optimal. I decided to dive into this topic to figure out how to perform automatic dependency generation in Makefiles.
Once figured out, it is actually not that hard. You can use build-in functionality of the GCC compiler to automatically generate a dependency file for each source-file. With a little GNU Make magic in the Makefile, you can then include these dependency files in the Makefile. As a result, only the source-file that actually depend on a specific header-file get rebuilt, after making a change in said header-file. If you’d like to find out how this was done, you can look at the diffs of the related commit.
Improved data throughput on RS232 and TCP/IP
While working on a bootloader customization project, I coincidentally found out that a small reconfiguration of the XCP packet sizes, can yield data throughput improvements. Specifically on RS232 and TCP/IP. The demo programs configured the packet sizes to 64 bytes for both receiving and sending XCP packets. This works fine, but is not yet optimized for how the PC tools communicate during a firmware update.
Here’s what LibOpenBLT does: It programs the firmware data in chunks of 256 bytes. It then splits these 256 bytes of to-be-programmed firmware data, into XCP PROGRAM and PROGRAM_MAX command packets. It favors PROGRAM_MAX packets, because these can carry one more byte of firmware data. This means that with an XCP packet size of 64:
- An XCP PROGRAM_MAX command carries 63 firmware data bytes.
- An XCP PROGRAM command carries up to 62 firmware data bytes.
To program 256 firmware data bytes, you would need 4 times a PROGRAM_MAX packet (252 bytes) and 1 PROGRAM packet (4 bytes).
Now by changing the XCP packet sizes from 64 to 129 bytes:
- An XCP PROGRAM_MAX command carries 128 firmware data bytes.
- An XCP PROGRAM command carries up to 127 firmware data bytes.
To program 256 firmware data bytes, you now only need 2 times a PROGRAM_MAX packet. After some performance testing I concluded that on RS232 this yields 8% better data throughput. On TCP/IP the data improvement highly depends on the latency of TCP/IP package on the network. Doing a firmware update with the microcontroller and PC both connected by Ethernet cable to a local router, the throughput improvement was a mere 3%. But this goes up significantly with more network latency. So if you’re using WiFi or if the PC and microcontroller boards are physically at different locations and communicate via several Internet hubs.
Based on these findings, I reconfigured the XCP packet sizes in all demo programs for RS232 and TCP/IP. This trick does not work for CAN or USB, because there the physical communication layer mandates the length of an XCP packet. On CAN it’s 8 bytes and for USB its 64 bytes, the endpoint size.
I am personally pleased with the state of the OpenBLT project. The income generated by the sales of commercial licenses, continues to support all maintenance and development efforts. You can read a bit more about this relationship between Feaser and the OpenBLT project in this blog article. Work on the next version already started. At this point it looks like it will see a few new microcontroller ports and demo programs.