User Tools

Site Tools


Bootloader Design

OpenBTL was designed with flexibility and portability in mind. The idea is that the bootloader can run on any type of microcontroller and with any type of data transfer interface for the actual firmware update. This chapter of the manual explains the internals of the bootloader design.


The bootloader's functionality and code is split up into 4 categories:

  • Application specific functionality. The code in this part is used to tailor the bootloader to your project specific needs. It contains function main(), the bootloader's configuration file and hook-functions that enable you to tweak the bootloader's behavior, without having to modify the bootloader's internals. For example, here you can implement functionality to control the opening and closing of the backdoor and the handling of the watchdog, if applicable.
  • Target independent functionality. This part is the core that drives the bootloader program. During software updates, it handles the data transfer from the firmware file to the microcontroller's memory. It forms the link between your application specifics and the hardware. There is no need for you to make any changes to this part of the bootloader. Communication between a host PC and the embedded bootloader follows the XCP version 1.0 protocol. Its official name is ASAM MCD-1 XCP V1.0.0 and it is a universal measurement and calibration protocol that defines a bus-independent, master-slave communication protocol to connect ECU's with calibration systems. More information can be found at
  • Target dependent functionality. When porting the bootloader to a new microcontroller, only this part requires modification. It contains the low-level drivers for accessing the communication, timer and memory peripherals.
  • Compiler specific functionality. This is a really a subcategory of the target dependent category. It contains code such as the c-startup routine and the interrupt vector table, which typically needs a little compiler magic to link to the correct memory location.

The bootloader itself is programmed once into the read-only memory of the microcontroller, typically the internal flash EEPROM and controls the main interrupt vector table. After every reset, the bootloader becomes active. It checks the checksum, that is calculated and programmed at the end of a firmware update, to determine if a valid user program is present. If this is the case it will start the user program and reroute the interrupts to the pseudo vector table. A so called backdoor can be used to force the bootloader to stay active. This can come in handy in case a faulty user program was programmed.


Refer to the following illustration for a detailed view of the modules in the bootloader's 4 categories. Understanding the modules makes it easier to navigate the bootloader source code.

State Machine

Typical uses cases are best described with reference to the bootloader's state machine:

Firmware update from a running user program

All OpenBLT demo programs are configured in a way that firmware updates can be started from a running user program (state user program active). When the user program receives the XCP CONNECT command from the host PC it activates the bootloader by performing a software reset. After reset, the bootloader keeps the so-called backdoor open for a pre-configured amount of time (BOOT_BACKDOOR_ENTRY_TIMEOUT_MS). The host PC will continuously send out the XCP CONNECT command until it received a response. If the XCP CONNECT command is received by the bootloader while the backdoor is open, it will send a positive response and keep the bootloader active for a firmware update, so suppressing the start of the (old) user program.

Once the firmware update is done, a software reset it performed where it first enters its entry state. After the backdoor time window elapses, a transistion occurs to the user program validation state. Here the user program checksum is calculated again and compared to the value that was programmed at the end of the firmware update. If the checksum is correct the bootloader assumes that the user program is valid and starts it (user program active).

If anything went wrong during the firmware update or the checksum validation failed, the bootloader defaults to its entry state. Here it waits and listens for a new firmware update request.

Firmware update from a backdoor entry

When the user program does not support bootloader activation or an incorrect user program was programmed that doesn't run, the bootloader can always be activated through the backdoor. The default implementation keeps the backdoor open for about 500ms (refer to the value of macro BOOT_BACKDOOR_ENTRY_TIMEOUT_MS) after each reset. This backdoor functionality can be changed to your application's needs through hook-functions. One often used configuration is one where the backdoor is always kept open based on the state of a digital input after reset. This enables you to simply flip a switch of press a pushbutton during reset and the bootloader stays active, instead of trying to start the user program. When the backdoor open condition was detected after reset (entry state), a transition to the idle state follows. Once in the idle state, the bootloader listens for the XCP CONNECT command from the host PC and transitions to the programming state once detected to handle the firmware update.

Communication sequence

During the firmware update procedure, the host PC sends XCP commands to the microcontroller target using the configured communication interface. The illustration below clarifies the sequence of XCP commands. Note that the host PC expects a response from the microcontroller target for each XCP command, with the exception of the PROGRAM_RESET command. Download the XCP 1.0 protocol specification for additional details.


The bootloader is configured through preprocessor statements in file blt_conf.h. In this header file you can select the communication interface that you want to use (UART, USB, CAN, SD-card, etc.) and you can enable which hook-functions the bootloader should call. Hook functions enable you to further customize the bootloader application, without having to make any modifications to the bootloader core:

manual/design.txt · Last modified: 2019/09/24 22:03 (external edit)