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.
After the OpenBLT version 1.5.0 release last month, development efforts for the next version were started right away. With the goal of having a transparent development process, this article provides an update on the ongoing development tasks. For those new to the OpenBLT project have a look at the recently published OpenBLT introduction video:
After half a year of development work, OpenBLT version 1.5.0 was officially released yesterday. Feel free to download the new version of the OpenBLT bootloader and take it for a spin yourself. This release is on track with the standard release cycle.
The main focus has been on getting the relatively new OpenBLT host library (LibOpenBLT) feature complete. This includes the BootCommander command-line program as well, since this one is build on top of LibOpenBLT.
Additionally, the support of the IAR, Keil and Atollic development environments was expanded, the SVN repository at SourceForge is now mirrored daily to a GIT repository at GitHub, and the Feaser website was localized to German.
This article describes in more detail what you can expect from the new OpenBLT release.
Goods news for all OpenBLT bootloader users that are interested in performing firmware updates on their microcontroller, via the Internet or from a local network. TCP/IP support was already available in the MicroBoot tool for Windows and is now also implemented in the cross-platform BootCommander command-line program.
The BootCommander program is based on the OpenBLT host library (LibOpenBLT), which means that TCP/IP is now also fully supported in LibOpenBLT. This completes the initial feature set envisioned for LibOpenBLT. It supports all the communication transport layers that are available in the OpenBLT bootloader itself: RS232, CAN, USB and TCP/IP.
This article provides instructions on how to obtain a copy of the OpenBLT bootloader that includes the new TCP/IP support, details regarding how the TCP/IP support was realized, and an example on performing a firmware update via TCP/IP and BootCommander.
Feaser is a provider of products and engineering services for microcontroller based embedded systems.
We develop and maintain the open source OpenBLT bootloader and are known for creating innovative and
customer oriented solutions that are delivered on time and within budget.