User Tools

Site Tools


This is an old revision of the document!

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 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 calling its entry function. This function is typically called EntryFromProg() and linked to a fixed memory address in the bootloader.

When the bootloader is activated this way, it directly enters the programming state to handle the firmware update. At the end of the firmware update, a checksum for the user program is calculated and programmed. Once done, a software reset it performed where it first enters its entry state. In this scenario, the backdoor is normally closed so it directly transitions 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 is waits and listens for a new firmware update request.

Firmware update from 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 50ms after each reset. This can be tuned to your application 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.

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