What type of support is available?
Projects in the embeddedd industry are complex and have tight deadlines. Deciding to integrate an open source software component, such as OpenBLT, into your software program can be a risk factor, if no professional and reliable technical support is available.

To eliminate this risk, professional support is available through Feaser, including:

• On-site integration
• Training
• Technical support by phone/e-mail

Feel free to contact Feaser to discuss your support needs.

Who can integrate the bootloader for my specific system?
The architecture of OpenBLT is optimized for portability and allows portation to pretty much any microcontroller based system.

Bootloaders are quite tricky and are critical for the overal functioning and reliability of the system. If the bootloader is not running correctly, it could become impossible to update the user program or, even worse, no longer starts the actual user program once programmed.

Feaser offers professional engineering services to integrate, customize and port OpenBLT to your specific requirements. Feel free to contact Feaser to discuss details and possibilities.

What is the ROM footprint of the bootloader?
The typical ROM size of OpenBLT is between 4 and 8 kilobyte. OpenBLT supports more than just one microcontroller family and compiler toolset, and allows compile-time configuration. Therefore it is not possible to give an exact number for the ROM footprint. Have a look at the MAP-file of the demo program for a more exact statistic regarding the ROM size.

How fast is the bootloader?
When configured to use UART wtih 57600 bits per second as the communication speed then the programming rate of the bootloader is typically around 3 to 3.5 kilobyte per second. The flash driver tasked with erasing and programming the flash EEPROM is optimized for run-time efficiency, however flash EEPROM operations do take time.

How does the bootloader know if a valid user program is present?
At the end of a programming session, the bootloader stores a program specific 32-bit checksum in non-volatile memory. When the bootloader is about to start the user program, this checksum is first verified and based on the results of this verification, the bootloader determines if it's safe to start the user program.

What is the backdoor entry?
Upon completion of a successful programming sequence, the user program is always started. Consequently, it would be up to the user program to reactivate the bootloader, whenever it needs reprogramming. But what if the user program, regardless of the reason, can no longer correctly reactivate the bootloader?

This is where the backdoor entry comes in to save the day. The backdoor allows the bootloader to be entered and activated, regardless of the user program. The default implementation keeps the backdoor open for typically 50ms. When a new programming sequence is started with the Microboot download utility, it continuously attempts to establish a connection with OpenBLT. If OpenBLT cannot be reactivated by the user program, simply reset the microcontroller and Microboot automatically connects and activates OpenBLT during the 50ms that the backdoor is open.

This implementation is user-friendly and does not depend on any additional hardware. The only downside is that the startup of the user program is always 50ms delayed. In case this delay is not acceptable, OpenBLT can be easily reconfigured to allow for an alternative backdoor entry implementation. For example, one that always keeps the bootloader active depending on the state of a digital input upon microcontroller reset. To implement your own backdoor entry through hook functions, change the BOOT_BACKDOOR_HOOKS_ENABLE configurable to 1 in file config.h.

How do I change the communication interface?
The configuration interface used by OpenBLT is configured in file config.h through the configurables BOOT_COM_XXX_ENABLE, where XXX specifies the communication interface, such as UART or CAN.

Thanks to OpenBLT's flexible architecture, new communication interfaces can be added. Feaser offers engineering services to add functionality to support any communication interface you desire. For example USB or TCP/IP. It is even possible for OpenBLT to load the new user program image from an SD-card.

Can I add functionality for programming an extra non-volatile memory device?
Yes, absolutely. By default OpenBLT contains a driver to operate on the internal non-volatile memory, which is flash EEPROM in most cases. Through hooks functions that are activated by setting the BOOT_NVM_HOOKS_ENABLE configurable to 1 (config.h), support can be added for 1 or more additional non-volatile memory devices, such as external flash EEPROM and serial EEPROMs. Feaser offers engineering services to add support for additional non-volatile memory devices.