The OpenBLT 1.19.0 release was made today, after another half year of development work. 9 tickets were processed, which resulted in 8 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.
![Image displaying the roadmap for the OpenBLT version 1.19.0 release.](https://www.feaser.com/en/blog/wp-content/uploads/2025/01/roadmap_openblt_release.png)
“A little bit of this and a little bit of that” best summarizes the new OpenBLT release. This article provides detailed information of what you can expect from the newly released OpenBLT version 1.19.0.
Packet checksum for XCP on RS232
As most of you know, the OpenBLT bootloader communicates according to the XCP protocol during a firmware update. For those interested in learning more about the XCP protocol, you can find a download link to the protocol specification in this section of the OpenBLT Wiki.
The specification includes XCP packet format details for all the supported transport layers. One of the optional features for the RS232 transport layer is the inclusion of a checksum byte at the end of the packet. When developing the OpenBLT bootloader, I skipped implementing support for this end of packet checksum byte. My reasoning behind this was that modern microcontroller systems mostly establish the RS232 link by means of a USB-RS232 converter. In this case, the encapsulating USB bulk packets already include checksum information.
However, when the RS232 link is established the conventional way (by cross-linking the Tx and Rx lines either with or without an RS232 transceiver), the link could be susceptible to noise and possibly resulting in flipped bits during the communication. The end of packet checksum can detect these flipped bit situations. Based on feedback I received from OpenBLT users, this setup is still used on occasion. For this reason I decided it’s time to implement and include support for this end of packet checksum byte in the OpenBLT release 1.19.0.
To enable this feature, you add the following configuration macro to your bootloader’s blt_conf.h
configuration header file:
/** \brief Configure data packet checksum type (0=none, 1=byte). */ #define BOOT_COM_RS232_CS_TYPE (1)
With this feature enabled in the bootloader, you also need to configure the PC tools to make use of it. In BootCommander you do this by adding the -ct=1
command line option. In MicroBoot you go to the “XCP on RS232” communication interface settings and select “Sum of Bytes” from the newly added “Checksum” drop-down box:
![Screenshot of the XCP on RS232 settings of MicroBoot, illustrating how to enable the end of XCP packet checksum.](https://www.feaser.com/en/blog/wp-content/uploads/2025/01/microboot_checksum_type_config.png)
For future reference, you can also find this information in this section of the OpenBLT Wiki.
Improved synchronization when connecting
When establishing a connection with the OpenBLT bootloader, the PC tools continuously send out the XCP Connect command to the microcontroller target, until the microcontroller sends the appropriate XCP response. How quickly the PC tools send out subsequent XCP Connect commands is configurable with the T6 XCP timeout, which has a default value of 50 milliseconds.
One OpenBLT customer added a Bluetooth BLE UART device to the PCB with the intend to perform firmware updates via UART in combination with the wireless Bluetooth link. While testing out firmware updates in this scenario, the MicroBoot PC tool just was not able to connect to the OpenBLT bootloader on the microcontroller target.
After thoroughly inspecting the communication logs, it turns out that somehow the used Bluetooth BLE UART device sent two times the same response to the XCP Connect command. MicroBoot interpreted this second XCP Connect response as the response to the subsequent XCP GetStatus command. Because this was not the proper response to the XCP GetStatus command, MicroBoot assumed that the connection failed.
An improvement to the LibOpenBLT library resolved the issue. The PC tools use this library for the communication with the OpenBLT bootloader. It now simply ignores the second unexpected XCP Connect response. This should also improve the overall synchronization when connecting to the bootloader on other transport layers as well.
Improved SysTick reset for ARM Cortex-M ports
As the title suggests, the reset of the system tick on the ARM Cortex-M ports needed an improvement. The bootloader performs this SysTick reset right before it starts the user’s firmware. The previous implementation resets the SysTick related registers back to their default reset values.
A few OpenBLT users reported that they noticed a problem in their own firmware, related to the SysTick. This happened primarily when their firmware used an RTOS. After some debugging, it turned out that the SysTick pending bit was still set. This caused the SysTick interrupt to execute the moment interrupts were enabled and this then happened when the RTOS was not yet initialized and not yet ready to properly process this SysTick event.
Luckily, the solution was simple: Clean the SysTick pending bit when the bootloader resets the SysTick:
![Screenshot of function TimerReset() highlighting the newly added improvement for clearing the SysTick pending bit.](https://www.feaser.com/en/blog/wp-content/uploads/2025/01/systick_improvement.png)
The new OpenBLT version 1.19.0 release includes this improvement for all ARM Cortex-M ports.
TCP/IP support for the Infineon TC375 Lite Kit demos
When developing the Infineon TC3 port a few years ago, I added demo programs for the TC375 Lite Kit board. At that point the demo programs supported firmware updates via both RS232 and CAN. The board also features an Ethernet connector, yet I didn’t get around to adding support for firmware updates via TCP/IP to the demo programs.
A few months ago one OpenBLT customer specifically requested this support, so about time to make it happen. It was a bit trickier than anticipated. I had the hardest time getting basic low-level packet transmission and reception working. Turns out it was related to the Tasking compiler included with the AURIX Development Studio. This one doesn’t do packed structures by default, nor does it feature a compiler flag for this. The uIP stack does rely on this feature. Long story short: I had to add a few Tasking compiler specific modifications to the uIP stack itself. If you search for #pragma pack 2
through the uIP stack, you’ll see the exact changes.
Included with the new OpenBLT 1.19.0 release are demo programs for the Infineon TC375 Lite Kit board that now support firmware updates via TCP/IP, in addition to RS232 and CAN.
Closing thoughts
Considering the new features and improvements that make up the OpenBLT version 1.19.0 release, I am quite satisfied with the current state of the bootloader. I would like to finish these release notes by thanking everyone for showing an interest in the OpenBLT bootloader project. Especially the ones who purchased the OpenBLT commercial license and the ones who keep renewing their support and maintenance contract. It is thanks to you that the OpenBLT project thrives and that is possible for Feaser to continue sponsoring the development and maintenance efforts.