The OpenBLT 1.10.0 release was made earlier today, after another half year of development work. 20 tickets were processed, which resulted in 57 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.
CANopen is a popular higher-layer protocol for a CAN based embedded distributed network. It provides a ready-to-use and proven blueprint for application data exchange between multiple nodes on a CAN network. Furthermore, CANopen includes network management functionality and pretty much everything else you need to get a CAN system up-and-running. Unfortunately, the CANopen protocol specification does not specify how a CANopen bootloader should behave. This article explains how you can make use of the OpenBLT bootloader in your CANopen network and rely on it for making firmware updates on your CAN nodes.
Over the past year requests started to trickle in for being able to run the OpenBLT bootloader on S32K11 and S32K14 microcontrollers. As a reaction to these requests, support for the entire NXP S32K microcontroller range was developed in the OpenBLT bootloader. The goal of this article is to describe in more detail how this support was realized and to point you in the right direction in case you want to start evaluating this bootloader solution for your NXP S32K based product. It is targeted towards those who are involved with developing hardware based on a NXP S32K microcontroller and looking for a flexible, reliable and readily available solution for performing firmware updates.
The OpenBLT bootloader ships with multiple demo programs for readily available and low cost microcontroller boards. These are great for familiarizing yourself with and evaluating the OpenBLT bootloader. But how do you get the OpenBLT bootloader running on your own microcontroller system? The goal of this article is to answer exactly this question.
When deciding on a bootloader solution, it is important to know how much of your microcontroller’s flash memory needs to be reserved for the bootloader. For the basic OpenBLT bootloader this is fairly easy to determine, as there are many demo programs available. You can simply rebuild a demo bootloader that is configured for a similar microcontroller. To get the bootloader size as small as possible, you could even follow the steps outlined in this blog article.
But what if you want to make use of one of the OpenBLT bootloader add-on modules that Feaser offers? These modules are not open source and only sold in combination with an OpenBLT commercial license. This article aims to answer exactly this question.
Continue readingOpenBLT version 1.9.0 was officially released yesterday, after another half year of development work. 14 tickets were processed, which resulted in 24 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.
Over the past 16 years, Feaser has been involved with a large number of embedded software projects for its customers. From the experience gained, it became clear that almost every firmware is in need of some common functionality. For example: critical sections, dynamic memory management and assertions. Almost every customer had their own implementation for this, which led to the idea to develop this functionality as a generic library. Hence, the MicroTBX project was born.
MicroTBX stands for Microcontroller ToolBoX and it is an embedded software library made up of software components commonly needed in firmware. MicroTBX is open source and released under the permissive MIT license, meaning that is it free to use for every embedded software developer and it can be integrated into closed sourced projects. At this point, the following software components are included:
Continue readingOpenBLT 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).
