The company Feaser and the OpenBLT bootloader project are two separate entities with a co-dependence. The goal of this article is to zoom in on this relationship and to explain why this relationship results in both entities to thrive.
As a consequence of the strong rise of smart and internet connected devices, there is an increased demand for embedded system security. As a result, more and more customers ask Feaser about the security options that are available, when the OpenBLT bootloader is incorporated into their microcontroller based product.
Security is needed in an embedded system to prevent unwanted third parties from tampering with the system and from stealing your intellectual property (IP). From the context of a bootloader, security options are meant to prevent unwanted third parties from
The OpenBLT bootloader already has several security options build-in that can be easily enabled. Together with readily available add-on modules and a few extra configuration steps, your system can be fully secured. This article describes the different levels of security available in a system with the OpenBLT bootloader.
In a system that contains a bootloader such as the OpenBLT bootloader, there are essentially two software programs present in read-only memory (ROM): your own firmware and the bootloader. Even though a bootloader is typically only integrated towards the end of the software development project, it is important to know up-front how much of the internal flash memory should be reserved for the bootloader. Otherwise you might end up in a situation where you realize too late that the microcontroller you selected does not have enough flash memory.
This goal of this article is to give you an indication of how much ROM the OpenBLT bootloader needs, for different configurations of firmware update media.
Several OpenBLT bootloader users asked, if it is possible two exchange data between the bootloader and their firmware. Even though the bootloader and your firmware are two completely separate programs in flash memory, which never execute at the same time, such a data exchange is definitely possible. This article presents a free-to-use software module that makes parameter exchange possible, by means of a shared section in RAM.
This data exchange is especially useful in a situation where you want to change the configuration and behavior of the bootloader in a way that was not yet known at the time that the bootloader was programmed into flash memory. For example to change the CAN identifiers the bootloader uses during a firmware update, based on a node-address that was dynamically assigned in your user program. Another example is to pass the IP-address on to the bootloader, which was assigned in your user program via DHCP.
This tutorial video contains a live Python coding session that demonstrates the creation of a custom firmware update tool in less than 30 minutes. To test the newly created firmware update tool, an ST Nucleo-F091RC board is used, but you can use any board that is supported by the OpenBLT bootloader. The Nucleo-F091RC board runs the demo programs that are available in the OpenBLT download package.
OpenBLT version 1.6.0 was officially released yesterday, after another half year of development work. 42 tickets were processed, which resulted in 140 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 details what you can expect from the new OpenBLT release.
Internally, the OpenBLT bootloader is based on the XCP communication protocol. XCP is a point-to-point protocol for establishing a connection between a host PC and a microcontroller. Now consider a system with multiple nodes, where each node consists of a microcontroller running the OpenBLT bootloader. Can you still perform a firmware update on each individual node? The short answer is: Yes, you can. This article explains how to configure the bootloader for this purpose.
The recommended way to get started with the OpenBLT bootloader is to first find a demo program, which is based on a microcontroller similar to the one in your system. Once you have gotten familiar with your selected demo bootloader, you can port it to your own system. The demo bootloader most likely supports more functionality than needed. This article explains how to scale down the bootloader configuration, with the goal of reducing the bootloader’s ROM footprint.
The example described in this article, references the Olimex STM32-P103 demo programs. These programs are configured for building with the GNU ARM Embedded toolchain and a Makefile. They were taken from OpenBLT version 1.5.0. The configuration of the default demo bootloader supports quite a bit: Firmware updates via UART, CAN and SD-card, resulting in a ROM footprint of about 20 kb. This article demonstrate how to reduce the ROM footprint of this demo bootloader from 20 kb to 4 kb.
MicroBoot is the graphical user interface application for initiating and monitoring the firmware update procedure. It is part of the OpenBLT bootloader package and forms the counter-part to the BootCommander application, which is console based.
The latest stable OpenBLT bootloader (version 1.5.0) contains a version of MicroBoot that works fine, but it only works under Microsoft Windows and it not yet based on the powerful OpenBLT host library (LibOpenBLT). The newly developed MicroBoot version 2 sets out to correct these two shortcomings. It uses LibOpenBLT under the hood and it is developed as a cross-platform application that runs under both Microsoft Windows and GNU/Linux operating systems.
The OpenBLT host library (LibOpenBLT), developed in 2017, adds interesting functionality to the OpenBLT bootloader project. It makes it possible for all users to quickly and easily develop their own firmware update tool, in the programming language of their liking. OpenBLT itself already ships with two firmware updates tools: MicroBoot for those that prefer a graphical user interface and BootCommander for those that prefer working from the command line.
Under the hood, BootCommander is already based on LibOpenBLT, but MicroBoot not yet. Another restriction of MicroBoot is that it’s not cross-platform and currently only runs under Windows. One of the planned efforts for this year is therefore to develop a version 2.0 of MicroBoot, such that it is cross-platform and builds upon LibOpenBLT.
A question that I mulled over for the past several months is: In what cross-platform integrated development environment (IDE) should MicroBoot 2.0 be developed? Personally, I am quite programming language and IDE agnostic; I’ll happily use whatever tools seem best for the task at hand.
While pondering the IDE selection question, I found the following potential candidates:
Eventually I settled on the Lazarus IDE. Initially, this might not strike you as the most obvious choice. However, using some tools borrowed from total quality management, it turns out this is the right IDE for the job. The goal of this article is to explain how and why I reached this conclusion.
