OpenBLT: a bootloader you can port to your own microcontroller

The problem: a shipped product that cannot be updated

The stated purpose is narrow and practical. OpenBLT enables you and your customers to update the firmware on a microcontroller based product. The motivation for it being open source is given as well, and it is a practical one rather than an ideological one: being open source means you can customise and tweak the bootloader to your specific needs.

That framing tells you what kind of component this is. It is not a hobby project and it is not a general purpose bootloader for hobby boards. It is infrastructure for a product that has already been built, shipped and installed, where a firmware bug discovered in the field would otherwise mean a physical service visit.

The target list is where the scope narrows again. OpenBLT is an open source bootloader for STM32, XMC, HCS12 and other microcontroller targets, and the documentation says it can be ported to any 8-bit, 16-bit or 32-bit microcontroller, and currently runs on ST STM32, Infineon XMC, NXP S12, and TI TM4C and LM3S microcontrollers. It is most popular on STM32, which tells you where the accumulated porting effort sits.

The porting claim is the ambitious part of the description. Porting to a family the project has not been run on is a real engineering task, not a configuration change, and the 8-bit end of that range is a long way from a desktop-class processor with plenty of flash to spare.

The transport list is the actual design decision

A bootloader is only as useful as the channel you can reach it over, and OpenBLT's list of supported interfaces is the part of the design that decides where it fits in a product.

By default it supports RS232, CAN, CAN FD, USB, TCP/IP and Modbus RTU, and performing firmware updates directly from an SD card is also supported.

Each of those implies a different installation. RS232 and Modbus RTU are for products with a serial port exposed to the field technician, often behind a legacy connector. CAN and CAN FD are for automotive and industrial shapes where the bus is already there. USB is for products with a socket the customer can reach. TCP/IP is for networked equipment where a firmware update can be pushed over the network the product already uses, and it is the interface that changes the most, because an update over a network needs its own security and rollback thinking. The SD card path is for devices where the customer has physical access to a slot but no network.

That breadth is the reason to use an existing bootloader rather than write one. The hard part of a bootloader is not moving bytes, it is entering the bootloader reliably from a running application, deciding when a firmware image is valid, and not bricking a device when an update is interrupted halfway. Those problems have been solved many times over for each of the transports above, and reusing that work is the entire value proposition.

The default set is a sensible starting point rather than a limit, since the project is open source and the point of it is to be adapted.

Three host tools, and the choice between them

The host side is where most of the friction of a bootloader lives, and the project offers three answers to the same problem.

MicroBoot is the easy-to-use PC tool for initiating and monitoring the firmware update, and it is the one a developer or a technician will reach for first. It is a graphical application, so it suits a production floor or a support desk where the operator should not have to learn a command line.

BootCommander is the command line program for people who prefer that, and for scripting a fleet of devices or for integrating the update into a build pipeline.

LibOpenBLT is the third option and the most interesting for a product team. It is an easy-to-use shared library that lets you develop your own firmware update tool quickly, in the programming language of your liking. If your product already has a configuration tool, or a commissioning app, or a service application, embedding the update capability in that is usually a better user experience than shipping a second program and training people to run it.

All three host tools are cross-platform and support both MS Windows and GNU/Linux, which matters more than it sounds, since a bootloader is often the one piece of the toolchain that has to work on whatever machine the technician has.

The cost of that choice is that you now own the integration. If you write your own tool against LibOpenBLT, the behaviour of that tool is yours, and the protocol details that OpenBLT implements become something you have to keep in step with the bootloader version on the device.

GitHub is a mirror, and the real repository is Subversion

The most important thing to know before you clone anything is that this GitHub repository is not where the project is developed. The description says it plainly: it is the official read-only mirror of the SVN OpenBLT bootloader repository, updated daily.

The actual source lives on SourceForge in a Subversion repository, and the project points at both, with the GitHub link offered for people who prefer Git. So a fork on GitHub is a fork of a mirror, and it will drift. Pull requests against the mirror are not the contribution path the project is set up for.

The mirror does tell you the shape of the source tree, and it is a sensible three part split:

Doc/
Host/
Target/

The documentation directory, the host side, and the target side, which is where the code for the supported microcontrollers lives. The host tree is what contains the tools, and the target tree is what you port when you move to a new microcontroller family. That split is what makes the porting claim plausible, because the protocol logic on the host and the bootloader logic on the target are separated.

There is a subtlety worth remembering when you plan an upgrade. The mirror is updated daily, so the master branch tracks the Subversion trunk rather than a release. There are no GitHub releases either, so there is no tag to pin to, and the meaningful version markers live in the Subversion history and in the download package on the project site. For a component that ends up on a device in the field, that difference between the trunk and a released version matters.

Dual licensing: GPL by default, commercial for closed source

The licensing is described in a way that leaves no room for confusion. OpenBLT is offered under a dual licensing model. The default licence is the GNU GPL, and if you plan to integrate OpenBLT into a closed source project, a commercial licence can be obtained from the vendor.

This is the usual structure for a firmware component that sits inside someone else's product, and it is worth understanding the boundary. Under the GPL, your bootloader and any code derived from it carry the copyleft obligation, and linking it into a closed source product is exactly the case the commercial licence exists for. The repository listing does not state a licence, and the readme names the GNU GPL as the default, so the file in the tree is the thing to read before you build on it.

The commercial terms sit with the sponsor, Feaser, which also offers integration and customisation services, support and maintenance contracts, and several add-on modules. Development and maintenance of OpenBLT is sponsored by Feaser, and the project page lists the licensing and contact links for both.

That arrangement has a shape worth naming. The code is open and the community can use it, but the commercial support, the customisation work and the closed source path all come from one vendor. For a product team that is often a good deal, because the people who know the porting details are the people who will support you. It also means the roadmap and the support boundary follow one company's priorities, which is a different risk profile from a project run by a wide community.

Getting started through the demo programs

The on-ramp is the download package rather than a repository clone, and that is a deliberate choice.

The OpenBLT download package contains numerous preconfigured demo programs for popular and low-cost development boards, and the documentation presents this as the way to get started with the bootloader quickly. That is the sensible starting point, because a bootloader is a component that has to work with a real flash layout, a real communication link and a real application that hands control over, and a working example on a board you already have removes all three unknowns at once.

The supporting material is spread across several channels. There is a FAQ for frequently asked questions and a wiki with in-depth information, both on the vendor's documentation site, plus a Twitter account, a developer blog, and a YouTube channel with video presentations and tutorials. The video material matters more here than it would for a library, because a large part of the work is the physical act of getting a device into the bootloader and observing the handshake, which is far easier to follow as a video than as a paragraph.

For an embedded project the practical sequence is therefore: take the demo package, get a board running, then read the porting documentation for the target you actually ship, and only then bring the bootloader into your own application and your own release process. The version you put on a device is the version your customers will live with for years, so the release discipline has to be part of the plan from the start.

Editorial conclusion

OpenBLT is worth evaluating if your product ships a microcontroller and you need field firmware updates without shipping hardware back, and if you value being able to read and adapt the bootloader code rather than accept a vendor's black box. It is the wrong choice if you need a turnkey solution for a microcontroller outside the supported families, or if the commercial licence cost is unacceptable, since closed source integration needs a separate agreement with the sponsor. Before you commit, read the porting documentation for your target, confirm that the transport you can physically reach in the field is one of the supported interfaces, and decide early whether the GPL or the commercial licence is the right basis for the product you are building.

Frequently asked questions

Official sources

1. feaser/openblt on GitHub
2. Issues
3. Project website
4. README