OpenBLT 1.10.0 release notes

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.

Image that shows the progress of the OpenBLT 1.10.0 release, based on the tickets that were worked on.

“Bigger and better” sounds like a suitable description for this new OpenBLT stable release. With bigger I do not mean ROM footprint, but the number of supported microcontroller families. Two new ports were added, including demo programs. Besides that a few improvements were made combined with some basic maintenance.

Newly supported ports and development boards

This release of the OpenBLT bootloader supports the following new microcontroller families:

Additionally, demo programs for the following development boards were added:

The demo programs support both the S32 Design Studio and IAR Embedded Workbench IDEs.

Refactored UART to RS232

Over the past years several customers contacted Feaser with the request if the bootloader can be customized to support firmware updates via RS485. This is of course not a problem. The system that was used for developing this support can be seen in the following illustration:

Overview of the system that was used for developing a customized version of OpenBLT that supports firmware updates via RS485.

On the PC side, the USB-RS485 converter from Olimex was selected. On the microcontroller side, the RS485 CAN shield from Waveshare was selected. It can be directly attached to the Nucleo-F401RE board to give it RS485 functionality.

The OpenBLT customization consisted of creating an RS485 communication driver in the microcontroller port. On the PC side a similar RS485 communication driver was added to LibOpenBLT. All that was left to do then was to make it possible to select and configure the new RS485 communication interface in both MicroBoot and BootCommander.

Anyways, this solution works and was delivered a few times to customers already. Since several requests for RS485 support came in, I figured it would be an option to officially add this support to OpenBLT, instead of doing one off customizations for this. The OpenBLT code base already contained a UART driver. In reality though, if was really an RS232 driver. So in preparation of developing RS485 support in the future, all UART occurrences in file names, function names and macro names were changed to RS232. In the mean-time, if you are already in need of firmware updates via RS485, feel free to contact Feaser to discuss what your options are.

Updated ST HAL libraries to the latest version

All STM32 demo programs and also the STM32 ports in OpenBLT are based on the ST HAL libraries. Around the beginning of the year several users reported compile problems, for example when building the bootloader for STM32F1 targets. It turns out that they were using a newer version of the ST HAL library. The CAN driver API was changed by ST, causing the compile errors. To correct this, all STM32 demo programs and ports were updated to use the latest version of the ST HAL libraries. This was quite a bit of work, but all part of keeping the OpenBLT bootloader maintained and up-to-date.

STM32 vector table base address configuration

Problem

Pretty much all customers who run the OpenBLT bootloader on STM32 microcontrollers, configure their microcontroller with the STM32CubeMX graphical software configuration tool. When generating code from STM32CubeMX, a function SystemInit() is generated. For example in system_stm32f7xx.c for the STM32F7. Function SystemInit() is automatically called by the reset handler, before function main(). One of the things that SystemInit() does, is to configure the base address of the vector table. Unfortunately, this base address is always hardcoded to the start of flash memory (0x08000000).

On a system that runs the OpenBLT bootloader, the bootloader is located at the start of flash and the user’s firmware comes after that. This means that when the user’s firmware is started by the bootloader, function SystemInit() is called and sets the base address of the vector table to the start of flash. This is incorrect, because that is where the vector table of the bootloader is located. The vector table base address should be set to where the vector table of the user’s firmware starts.

The sad part is that the bootloader actually already properly does this step. It sets the vector table base address to the user’s firmware vector table right before the user’s firmware is started. But then function SystemInit() puts salt in the wound by overwriting this configuration with an incorrect one.

Solution

The solution so far was that the OpenBLT port documentation included instructions to comment out the code in the generated function SystemInit() that reconfigured the vector table base address (SCB->VTOR = ...). This works, but it is a problem waiting to happen. The user needs to do this each and every time that they generate the code with STM32CubeMX. Sooner or later someone forgets it and then their firmware crashes when the bootloader starts it.

For this reason, I implemented a better solution in the demo programs. All affected STM32 demo user programs now explicitly reconfigure the vector base address to the start of the vector table. So not the start of flash memory. This way this change only needs to be processed once in your firmware and is not dependent on the code generated by STM32CubeMX. Here is an example of what this function looks like when using the Atollic TrueSTUDIO IDE:

/************************************************************************************//**
** \brief     Vector base address configuration. It should no longer be at the start of
**            flash memory but moved forward because the first part of flash is
**            reserved for the bootloader. Note that this is already done by the
**            bootloader before starting this program. Unfortunately, function
**            SystemInit() overwrites this change again. 
** \return    none.
**
****************************************************************************************/
static void VectorBase_Config(void)
{
  /* The constant array with vectors of the vector table is declared externally in the
   * c-startup code.
   */
  extern const unsigned long g_pfnVectors[];

  /* Remap the vector table to where the vector table is located for this program. */
  SCB->VTOR = (unsigned long)&g_pfnVectors[0];
} /*** end of VectorBase_Config ***/

All you now have to do is add this function before main() and call it as the first thing in function main(). This means that this new code runs after SystemInit() and corrects the problem.

Overall state of the OpenBLT bootloader project

Even in the time of Corona-virus, the OpenBLT bootloader project is going strong. I anticipated that commercial license sales through Feaser would drop a bit this year, due to the global state of the economy. To my surprise the opposite is true. This means that Feaser can keep on sponsoring the OpenBLT project, just like the past years and that all is looking really good for the long term success of the OpenBLT project. I hope you enjoy working with the new OpenBLT 1.10.0 release.

This entry was posted in OpenBLT and tagged , . Bookmark the permalink.