Navigation
External Links
Donate
Show your appreciation for OpenBLT
and support future development by
donating.
External Links
Donate
Show your appreciation for OpenBLT
and support future development by
donating.
This is an old revision of the document!
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:
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.
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).