OpenBLT version 1.8.0 was officially released today, after another half year of development work. 21 tickets were processed, which resulted in 35 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.
The goal of this blog article is to answer a support question that has been asked by several OpenBLT bootloader users: How can my own firmware read the version of the bootloader? The bootloader defines three macros that combined hold the bootloader version number. These macros are update each time a new version of the bootloader is released. You can find these macros in the “boot.h” header-file:
When you perform a text search for these macros through the bootloader’s sources, you’ll notice that the macros are not actually used. The idea is that they are available for you to use any way you prefer. You could for example customize the bootloader’s internally used communication protocol (XCP) such that the version number is read out by the PC tools MicroBoot and BootCommander. Although you are free to do so, most users prefer to not touch the bootloader’s core code and instead they want to access the bootloader’s version number from their own firmware. This article contains an example on how to do just that.
Continue readingOpenBLT version 1.7.0 was officially released yesterday, after another half year of development work. 37 tickets were processed, which resulted in 136 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.
The main focus points for this release were: (1) Enhancing the security features offered by the bootloader. (2) Improving support for firmware updates via TCP/IP. (3) Porting the bootloader to the STM32F7 microcontroller family. (4) Completing the conversion of all STM32 ports and demo programs from the Standard Peripheral Library (SPL) to the Hardware Abstraction Layer (HAL).
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.
