OpenBLT 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).
Enhanced security features
Security for embedded systems is a hot topic nowadays and this applies to bootloaders as well. An ever increasing amount of OpenBLT users do no just want to be able to perform firmware updates, but also make sure that they have control over who can perform the actual firmware update. Additionally, they want to prevent unwanted parties from reading out their firmware to protect their IP. The OpenBLT bootloader can meet all these security requirements, as outlined in this blog article.
One of the security features is that you can lock access to the memory read, erase and program operations supported by the bootloader’s XCP communication protocol. Access to these operations is only granted to those that properly unlock it through a seed/key sequence. This was already supported in previous versions of the OpenBLT bootloader, however the byte length of both the seed and the key was limited by the maximum configured XCP packet size. This turned out to be a real bottleneck for those performing firmware updates via controller area network (CAN). A CAN message, and therefore also an XCP packet, can only have 8 data bytes. This only left 6 bytes for the seed and the key, after excluding XCP protocol overhead bytes. The key computation algorithm is of course the most important factor when it comes to the seed/key protection, but a longer seed and key also helps a lot. The longer the seed and key, the harder it is to crack the seed/key protection. In the new bootloader release, the seed and key can be split over multiple XCP packets. This makes it possible to have seed and key lengths of up to 255 bytes.
Some OpenBLT users reported that they in general just do not want others to be able to read out memory contents via the bootloader’s XCP communication protocol, regardless of the seed/key protection. This is now also supported by setting the macro
BOOT_XCP_UPLOAD_ENABLEto 0 in the “blt_conf.h” configuration header file.
Improved support for firmware updates via TCP/IP
Support for firmware updates via TCP/IP was added several years ago already. Although fully functional it was not yet optimal. For example, it was only possible to use static IP addresses. The new bootloader release features DHCP support for automatic IP address assignment. It is enabled by setting the macro
BOOT_COM_NET_DHCP_ENABLEto 1 in the “blt_conf.h” configuration header file.
Another not optimal part was that the bootloader always initialized its TCP/IP stack during startup to be able to detect new firmware update requests. Depending on your network configuration, this could take somewhere up to 10 seconds. Since the bootloader always runs first after a reset, this resulted in a significant startup delay of your own firmware. The bootloader now supports a so called deferred initialization sequence. This simply means that the bootloader does not initialize its TCP/IP stack by default and therefore getting rid of the startup delay. When the (optional) deferred initialization sequence is enabled, the TCP/IP stack is only initialized (a) when no firmware is present or (b) when explicitly requested. For example, most systems that support firmware updates via TCP/IP have TCP/IP functionality in their firmware as well. Their firmware can detect new firmware update requests, after which it starts the bootloader via a software reset. Through the shared parameters module presented in this blog article, the firmware can pass on the request to the bootloader to explicitly initialize the TCP/IP stack such that the firmware update can go through.
Support for the STM32F7 microcontroller
More and more requests came in for running the OpenBLT bootloader on the STM32F7 family of microcontrollers. As a response, the port for the STM32F7 was developed and demo programs were added for the Nucleo-F746ZG board. The demo programs are configured to support firmware updates via both RS232 and CAN. Additional support for firmware updates via USB and TCP/IP is planned for the future.
STM32F1 and STM32F4 converted from SPL to HAL
With the previous release, an effort was started to convert all STM32 ports and demo programs from the Standard Peripheral Library (SPL) to the Hardware Abstraction Layer (HAL). The STM32F1 and STM32F4 were still using the SPL. With the new version 1.7.0 of the OpenBLT bootloader, all STM32 ports and demo programs are now converted to HAL.
I am quite happy with all the new features and improvements that are available in this release of the bootloader. If you read this and the previous release notes, you’ll notice that most changes are driven by requests from the community. I believe that listening closely to what users want and then realizing these requests, is a key success factor of the OpenBLT bootloader project. With this in mind, feel free to pass on your ideas and wishes for a future version of the OpenBLT bootloader.