Frequently Asked Questions

What is the history of the OpenBLT bootloader project?

The OpenBLT project started out as a hobby project that Frank Voorburg developed on the side in his spare time. Not long after publishing the project as open source at SourceForge, companies contracted him to perform bootloader integrations and customizations for them.

Interest in the OpenBLT project grew consistently and continuously over the following years, resulting in a switch to a dual licensing model and Frank Voorburg reorganizing his company Feaser. Feaser is now fully dedicated to providing professional engineering services and commercial licenses around the OpenBLT bootloader. More details about the history of the OpenBLT project is available in this blog article.

One of the main factors contributing to the success of the OpenBLT project is the synergy between the company Feaser on the one hand and the open source OpenBLT project on the other hand. The OpenBLT project generates income for Feaser, which makes it possible for Feaser to fully sponsor the development and maintenance efforts of the OpenBLT project. This blog article contains more information about the relationship between Feaser and the OpenBLT project.

Why should I use the OpenBLT bootloader?

Because it is not just another bootloader. The ecosystem around the OpenBLT project offers something unique that currently cannot be matched by any other bootloader product. We dedicated an entire article, describing the unique selling points of the OpenBLT bootloader, to answer this question.

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 licensing options are available?

The bootloader will always be open source and available for free under the GNU GPL version 3 license. Under this license you can make use of the bootloader, if your firmware is also open source and compatible with the GNU GPL version 3 license.

If the firmware for your microcontroller is closed source and you integrate the OpenBLT bootloader, then your are creating a combined work. In this case your firmware will also fall under the GNU GPL version 3 license and you are required to open source your firmware.

If you would like to keep your proprietary firmware closed source, then we can make OpenBLT available to you under a commercial license. Refer to the license comparison table for more details.

How do I obtain a commercial license for the bootloader?

Contact Feaser to request a quote for a commercial license. Also let them know what type of microcontroller you intend to use, because a commercial license is tied to a specified microcontroller family (i.e. STM32F1).

Note that all revenues generated from commercial licenses is invested back into keeping the OpenBLT project alive. It enables us to spend more time on development and maintenance.

What do I receive after ordering the commercial license?

After submitting your purchase order, Feaser prepares a bootloader package specifically for the microcontroller family that you ordered the commercial license for. It is based on the latest OpenBLT stable release, but all references to the GNU GPL are removed and your commercial license is added as a PDF file.

As an extra service, a demo bootloader and demo user program are added for a microcontroller similar to the one you plan on using. The demo programs can be built with the compiler toolchain that you specified and the demo bootloader is preconfigured for the same firmware update media that you plan on using. Additionally, a detailed getting started user manual is added to help you get the bootloader up and running as quickly as possible. The results of the bootloader integration are delivered to you electronically as a zip-archive.

Note that Feaser also offers services to perform this OpenBLT bootloader integration directly on your hardware.

What are the restrictions of the commercial license?

The only real restriction of the commercial license is that you cannot redistribute your commercially licensed version of OpenBLT to third parties in source code format (including your customers and users). Binary format (object-code or executable) is of course allowed.

Feel free to contact Feaser to request a sample of the commercial license, for reviewing purposes.

Do I have to pay royalties?

No. At this point the commercial license is a one-time fee, so no additional per product royalties have to be paid.

What does the bootloader release schedule look like?

New stable releases are made twice per year. One in January and one in July. In between these planned releases, it is possible that one or more patch releases are made. This happens when the development of a new feature was completed that users are waiting for or when important bug fixes were made.

More details about the release schedule and bootloader version numbers can be found in this blog article.

What security options are available in the bootloader?

From the context of a bootloader, security options are meant to prevent unwanted third parties from

  • Making firmware updates on your product.
  • Capturing your firmware data while it is communicated to your product during a firmware update.
  • Reading out your firmware data after it was programmed onto your product.

The OpenBLT bootloader already has several security options build-in that can be easily enabled. Together with readily available add-on modules and a few extra configuration steps, your system can be fully secured. Have a look at this blog article, which lists the available security options and explains in detail how to enable them.

What is the ROM footprint of the bootloader?

The ROM size of the OpenBLT bootloader is mostly dependent on the communication media you intend to enable for firmware updates. It is typically somewhere in the range of 5 to 20 kilobyte. We dedicated an entire blog article to this topic to give you more details.

Tips and tricks on further reducing the ROM footprint of the bootloader can be found in this blog article.

What communication protocol is used during firmware updates?

The OpenBLT bootloader utilizes the standardized XCP protocol to communicate with the microcontroller target during the firmware update procedure. The XCP protocol is maintained and published by the The Association for Standardization of Automation and Measuring systems (ASAM).

The XCP protocol, officially called ASAM MCD-1 XCP, is a universal measurement and calibration protocol. It is a master-slave communication protocol to connect a microcontroller (slave) with a calibration and data acquisition system (master). Since the protocol contains features for non-volatile memory erasure and programming, it is quite suitable for the purpose of firmware updates as well.

The XCP protocol was selected because it contains everything you could wish for in a communication protocol for a bootloader:

  • It includes features for non-volatile memory programming.
  • It supports multiple transport layers such as UART, CAN, USB, TCP/IP and be easily be embedded inside other transport layers.
  • It features a build-in seed/key security mechanism for restricting access.
  • The protocol distinguishes between mandatory commands and optional commands. This allows the implementation to have a low ROM footprint by stripping out those optional commands that are not needed for the purpose of a firmware update.

For more details you can download a copy of the XCP 1.0 protocol specification and you can have a look at the bootloader’s communication sequence chart.

Although we highly recommend the XCP protocol, it is definitely possible to replace it with another communication protocol, thanks to the bootloader’s modular architecture.

Can I exchange data between the bootloader and my firmware?

The bootloader and your firmware are two separate programs in flash memory that never run at the same time. It is possible to exchange data between the two programs by means of a shared RAM section. Feaser developed and presented a free-to-use “shared parameter” module in a blog article for exactly this purpose.

Such a data exchange is especially useful in a situation where you want to change the configuration and behavior of the bootloader in a way that was not yet known at the time that the bootloader was programmed into flash memory. For example to change the CAN identifiers the bootloader uses during a firmware update, based on a node-address that was dynamically assigned in your user program. Another example is to pass the IP-address on to the bootloader, which was assigned in your user program via DHCP.

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.

Note that this 32-bit checksum is calculated over only a small portion of your software program, typically a part of the interrupt vector table. It is meant as a signature that helps the bootloader to determine if a software program is present or not. To have a checksum verification over the entire contents of your software program, Feaser offers the improved checksum add-on module.

How do I debug my own firmware, when the bootloader is also present in flash?

If your embedded system makes use of the OpenBLT bootloader, then essentially you have two software programs present in flash memory: your own firmware and the OpenBLT bootloader. This added complexity can cause a problem when trying to debug your firmware.

The OpenBLT bootloader writes a 32-bit checksum to flash memory at the end of the firmware update. It is used as a signature to determine if firmware is present or not. When programming your firmware with the debugger instead, this checksum value does not get written, resulting in the bootloader not starting your firmware during a debug session.

A simple workaround is to program your firmware with the OpenBLT bootloader, so using the MicroBoot and/or BootCommander PC tool. Then in your integrated development environment you can configure your debugger session such that it does not flash code, but only loads debugger symbols.

The downside of this approach is that there is an extra step involved each time you start a debug session. Additionally, flashing your firmware with the debugger is typically quicker that using a bootloader. With a few small workarounds, you can get full debug functionality back for your firmware. A detailed explanation on how to accomplish this can be found on the developer blog.

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 after reset. Although this time depends on the used communication interface. 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 time windows 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 delayed by the backdoor open time window (BOOT_BACKDOOR_ENTRY_TIMEOUT_MS). 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 blt_conf.h.

How do I change the communication interface?

The configuration interface used by OpenBLT is configured in file blt_conf.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.

How can I disable the assertions?

By default, both compile-time (ASSERT_CT) and run-time assertions (ASSERT_RT) are enabled. Think of them as safeguards and debugging aids when you are modifying the bootloader. There is nothing wrong with leaving assertions on all the time, as they protect against incorrect configuration and behavior of the bootloader.

Some user prefer to differentiate between a debug version and a release version of their bootloader, where the release version disables the assertions. Disabling the assertions in OpenBLT is quite easy. All you have to do is define the NDEBUG macro. Ideally, you add it as a compiler flag. With GCC this would be “-DNDEBUG”. Alternatively, you can add the following line at the top of assert.h:

#define NDEBUG

An added benefit of disabling the assertions, is that it lowers the ROM footprint of the bootloader. So if you are trying to squeeze the bootloader in as little ROM as possible, then disabling the assertions is a good approach, when you create the release version of your bootloader.

Can I use the bootloader on multiple nodes in a network?

Internally, the OpenBLT bootloader is based on the XCP communication protocol. XCP is a point-to-point protocol for establishing a connection between a host PC and a microcontroller. It is possible to use the bootloader in a network with multiple nodes. You just need to make a minor configuration change to make each node individually addressable. This is explained in detail in this blog article.

How can I use 29-bit extended CAN identifiers instead of 11-bit standard?

The bootloader uses two CAN identifiers. One for sending command messages from the host and one for receiving response messages. These identifers are configured in blt_confg.h with the macros BOOT_COM_CAN_RX_MSG_ID and BOOT_COM_CAN_TX_MSG_ID, respectively. Simply OR the identifier with bitmask 0x80000000 to configure the identifier as 29-bit extended. More details can be found at the bottom of this blog article.

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 (blt_conf.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.

Is the bootloader robust over power failures or loss of communication during firmware updates?

As the last programming step, a checksum value is programmed into flash memory at a fixed location. This is not a checksum of the entire firmware, but typically just a checksum of the vector table. It serves as a marker to determine if the firmware was completely programmed or not. Upon each microcontroller reset, the bootloader always runs first and check for this checksum marker. If it is not correct, then the user program is not started and the bootloader remains active, which allows the firmware update to be restarted.

Can I change the checksum mechanism myself?

By setting the configuration macro BOOT_NVM_CHECKSUM_HOOKS_ENABLE to 1 in blt_conf.h, hook functions become available (NvmWriteChecksumHook() and NvmVerifyChecksumHook()) that allow you to implement your own checksum mechanism. Some customers prefer the checksum to not be just a marker for user program presence, but a checksum over the entire user program. For this, you could add checksum information to the firmware's S-record in a post-build step at a fixed (reserved) address, such as the first and last addresses and the actual checksum. The newly available hook functions can then access this checksum information to perform a full checksum verification.

During a firmware update, is the firmware first downloaded to RAM?

Short answer: No. The new firmware is communicated to the bootloader and programmed into flash memory in small chunks of data. Typically 7 to 64 bytes, depending on the used communication interface (CAN, UART, USB, etc). Thanks to this feature, the bootloader can also run on low-end microcontrollers with limited RAM.

How does a firmware update work?

The firmware update sequence is as follows:

  1. The flash memory, which is to be rewritten, is erased.
  2. The new firmware is communicated to the bootloader and programmed into flash memory in small chunks of data. Typically 7 - 64 bytes, depending on the used communication interface (CAN, UART, USB etc).
  3. As the last programming step, a checksum value is programmed into flash memory at a fixed location. This is not a checksum of the entire firmware, but typically just a checksum of the vector table. It serves as a marker to determine if the firmware was completely programmed or not.
  4. Once done, the new software program is started after performing a checksum verification.
faq.txt · Last modified: 2019/04/18 21:57 by voorburg
 
Powered by PHP Driven by DokuWiki