User Tools

Site Tools


manual:design

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.

Architecture

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 http://www.asam.net/.
  • 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.

Modules

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.

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.

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).

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