User Tools

Site Tools


manual:design

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
manual:design [2013/05/29 18:24]
voorburg [Modules]
manual:design [2016/12/17 11:50]
voorburg [State Machine]
Line 1: Line 1:
 ====== Bootloader Design ====== ====== 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. 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 ===== ===== Architecture =====
 +
 The bootloader'​s functionality and code is split up into 4 categories: 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.   * **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 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.   * **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.   * **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.
 +
 \\  \\ 
 +
 {{:​manual:​openblt_architecture.png?​900|}} {{:​manual:​openblt_architecture.png?​900|}}
 +
 +
  
 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. 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 ===== ===== 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. 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.
 +
 +
  
 {{:​manual:​openblt_modules.png?​700|}} {{:​manual:​openblt_modules.png?​700|}}
 +
 +
  
 ===== State Machine ===== ===== State Machine =====
 +
 Typical uses cases are best described with reference to the bootloader'​s state machine: Typical uses cases are best described with reference to the bootloader'​s state machine:
  
 {{:​manual:​openblt_statemachine.png?​900|}} {{:​manual:​openblt_statemachine.png?​900|}}
  
-**Firmware update from a running user program** ​\\  +**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 calling ​its entry functionThis function ​is typically called EntryFromProg() and linked ​to a fixed memory address ​in the bootloader. ​+ 
 +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// stateAfter 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 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 {{:​manual:​xcp_1_0_specification.zip|XCP 1.0 protocol specification}} for additional details. 
 + 
 + 
 + 
 +{{:​manual:​openblt_xcp_sequence.png?​693|}} 
 + 
 + 
  
-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. +===== Customization =====
- \\  +
- ​\\ ​+
  
-**Firmware update from a backdoor entry** \\  +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-cardetc.) and you can enable which hook-functions the bootloader should callHook functions enable ​you to further customize ​the bootloader ​applicationwithout having ​to make any modifications ​to the bootloader ​core:
-When the user program does not support bootloader activation or an incorrect user program was programmed ​that doesn'​t runthe bootloader can always be activated through the backdoorThe 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 resetThis enables ​you to simply flip a switch of press a pushbutton during reset and the bootloader ​stays activeinstead 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:​openblt_customization.png?​900|}}
manual/design.txt · Last modified: 2019/09/24 22:03 (external edit)