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.
For testing purposes, the demo bootloader for the Olimex STM32-E407 board was used from the latest OpenBLT stable release (version 1.6.0). The STM32-E407 demo bootloader supports all firmware update media (RS232, CAN, USB, TCP/IP and SD-card), making it the perfect candidate for the tests.
Most commercial licenses were sold for STM32 microcontroller families the past years, so this covers the widest user base. Most users build their software with either a GCC based IDE, such as Atollic TrueStudio or the IAR Embedded Workbench for ARM. For this reason, the tests were run with both these IDEs. Note though that these tests are not meant as a comparison in compiler toolchain performance. It is only meant to give you an idea of how much ROM is needed by the OpenBLT bootloader.
Each test case consists of building the bootloader for just one specific firmware update media. The following macros in the “blt_conf.h” configuration header file were given a value of 0 or 1 to disable or enable the firmware update media, respectively:
BOOT_COM_UART_ENABLEfor firmware updates via RS232BOOT_COM_CAN_ENABLEfor firmware updates via CANBOOT_COM_USB_ENABLEfor firmware updates via USBBOOT_COM_NET_ENABLEfor firmware updates via TCP/IPBOOT_FILE_SYS_ENABLEfor firmware updates from an SD-card
Both the IAR and GCC compilers were configured to optimize for size and the linkers such that unused functions are removed from the final executable. The following table provides an overview of the test results:
Keep in mind that the ROM size reserved for the OpenBLT bootloader must always be aligned to the erase sectors as defined by the flash EEPROM hardware. This is because it is not possible to erase just a single byte in flash EEPROM. Erasure can only be done on sectors. To get an idea for the erase sector sizes on your microcontroller, you can have a look at array flashLayout[], which is located in the OpenBLT port’s “flash.c” source-file.
For example, the first four sectors of flash on the STM32F407 microcontroller are each 16 kbyte. This means that at least 16 kbyte must be reserved for the OpenBLT bootloader, even if it is configured for firmware updates via RS232, which fits in less that 5 kbyte.
Once you know the ROM size that your OpenBLT bootloader configuration needs, the instructions in this blog article explain how to actually change the amount of ROM that is reserved for the OpenBLT bootloader.
As you can see in the table with test results, the ROM footprint of the OpenBLT bootloader is highly dependent on the firmware update media that you intend to use in your product. When your product has a different microcontroller embedded, you can re-run these tests on an OpenBLT demo bootloader that is configured for a microcontroller that is closer to the one you have. Note that Feaser offers portation services in case your selected microcontroller is not yet supported by the OpenBLT bootloader.
The information in this article gives you a good idea of how much flash memory should be reserved for the OpenBLT bootloader and hopefully helps you with selecting the right microcontroller for your product.
