Memory requirements of the OpenBLT add-on modules

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.

Available OpenBLT add-on modules

At this point, Feaser offers three add-on modules for the OpenBLT bootloader: A firmware encryption module, an improved checksum module and a master/slave gateway module. Here follows a brief description of these modules.

The firmware encryption module enables you to encrypt the program code of your firmware file. During a firmware update, your program code is communicated in the encrypted format and decryption takes place right before it is written to flash memory. You no longer have to worry about an unwanted third party reverse engineering your firmware, if they get a hold of your firmware file or monitor the communication stream during a firmware update.

The improved checksum module calculates and verifies the checksum over your firmware’s entire code, as opposed to just a small part in the case of OpenBLT’s default checksum mechanism. With this module you can be assured that the bootloader only starts your firmware when all the bits of the firmware’s code are correct in flash memory.

The master/slave gateway module makes it possible to update both the master and the slave(s) in a master/slave system. A connection-mode parameter makes it possible to select either the master or a slave for the firmware update. When a slave is selected, the gateway is activated, allowing the firmware update communication to reach the slave through the master.

Measurement of memory consumption

To measure the ROM and RAM requirements of the add-on modules, they were individually integrated into the Nucleo-F103RB demo bootloader of the recently released OpenBLT version 1.9.0. The GNU ARM Embedded toolchain version 8-2018-q4-major was used for building the bootloader.

The amount of ROM and RAM consumed by the add-on modules, is dependent on the configured compiler optimization. For this reason the tests were repeated for three different compiler optimizations:

  • Compiler optimizations turned off (-O0). This setting is typically not used in a production version of the software. It leads to unnecessarily large firmware that therefore also runs slower. It is just handy during debugging when setting breakpoints and stepping through the code.
  • Compiler optimization for the smallest possible code size (-Os). This is a good setting if you really need to squeeze the last bytes out of your firmware to make it as small as possible. Not recommended when debugging your code.
  • Compiler optimization for debugging (-Og). This is a great default setting for all your embedded firmware projects. It does a decent amount of optimization to reduce the code size, while still making it possible to perform debugging.

The test results can be found in the following table:

Taking the recommended -Og compiler optimization, all add-on modules combined require about 3.3 kbyte of flash memory and 240 bytes of RAM.

The information presented in this article gives you a good insight into how much memory is needed by the OpenBLT add-on modules. Feel free to contact Feaser for additional questions.

Follow and like us:
This entry was posted in OpenBLT and tagged , , . Bookmark the permalink.