manual:design
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
manual:design [2016/10/24 10:07] voorburg [State Machine] |
manual:design [2019/09/24 22:03] (current) |
||
|---|---|---|---|
| Line 47: | Line 47: | ||
| **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 performing a software reset. After reset, the bootloader keeps the so-called backdoor open for a pre-configured amount of time (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. | + | 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//). | 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//). | ||
| Line 55: | Line 55: | ||
| **Firmware update from a backdoor entry** | **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 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. | + | 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. |
manual/design.1477296460.txt.gz ยท Last modified: 2019/09/24 22:11 (external edit)
Page Tools
