faq
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
faq [2019/10/24 20:22] voorburg |
faq [2020/02/14 12:59] voorburg |
||
|---|---|---|---|
| Line 86: | Line 86: | ||
| Tips and tricks on further reducing the ROM footprint of the bootloader can be found in [[https://www.feaser.com/en/blog/?p=174|this blog article]]. | Tips and tricks on further reducing the ROM footprint of the bootloader can be found in [[https://www.feaser.com/en/blog/?p=174|this blog article]]. | ||
| + | |||
| + | **__What are the ROM footprints of the OpenBLT add-on modules??__** \\ | ||
| + | |||
| + | The [[https://www.feaser.com/en/addons.php#encryption|firmware encryption]] module requires about 1800 bytes, the [[https://www.feaser.com/en/addons.php#checksum|improved checksum]] module about 700 bytes and the [[https://www.feaser.com/en/addons.php#gateway|master/slave gateway]] module about 900 bytes. We dedicated an entire [[https://www.feaser.com/en/blog/?p=347|blog article]] to this topic to give you more details. | ||
| **__What communication protocol is used during firmware updates?__** \\ | **__What communication protocol is used during firmware updates?__** \\ | ||
| Line 95: | Line 99: | ||
| The XCP protocol was selected because it contains everything you could wish for in a communication protocol for a bootloader: | The XCP protocol was selected because it contains everything you could wish for in a communication protocol for a bootloader: | ||
| * It includes features for non-volatile memory programming. | * It includes features for non-volatile memory programming. | ||
| - | * It supports multiple transport layers such as UART, CAN, USB, TCP/IP and be easily be embedded inside other transport layers. | + | * It supports multiple transport layers such as RS232, CAN, USB, TCP/IP and be easily be embedded inside other transport layers. |
| * It features a build-in seed/key security mechanism for restricting access. | * It features a build-in seed/key security mechanism for restricting access. | ||
| * The protocol distinguishes between mandatory commands and optional commands. This allows the implementation to have a low ROM footprint by stripping out those optional commands that are not needed for the purpose of a firmware update. | * The protocol distinguishes between mandatory commands and optional commands. This allows the implementation to have a low ROM footprint by stripping out those optional commands that are not needed for the purpose of a firmware update. | ||
| Line 111: | Line 115: | ||
| **__How fast is the bootloader?__** \\ | **__How fast is the bootloader?__** \\ | ||
| - | When configured to use UART wtih 57600 bits per second as the communication speed then the programming rate of the bootloader is typically around 3 to 3.5 kilobyte per second. The flash driver tasked with erasing and programming the flash EEPROM is optimized for run-time efficiency, however flash EEPROM operations do take time. | + | When configured to use RS232 wtih 57600 bits per second as the communication speed then the programming rate of the bootloader is typically around 3 to 3.5 kilobyte per second. The flash driver tasked with erasing and programming the flash EEPROM is optimized for run-time efficiency, however flash EEPROM operations do take time. |
| **__How does the bootloader know if a valid user program is present?__** \\ | **__How does the bootloader know if a valid user program is present?__** \\ | ||
| Line 139: | Line 143: | ||
| **__How do I change the communication interface?__** \\ | **__How do I change the communication interface?__** \\ | ||
| - | The configuration interface used by OpenBLT is configured in file blt_conf.h through the configurables BOOT_COM_XXX_ENABLE, where XXX specifies the communication interface, such as UART or CAN. | + | The configuration interface used by OpenBLT is configured in file blt_conf.h through the configurables BOOT_COM_XXX_ENABLE, where XXX specifies the communication interface, such as RS232 or CAN. |
| Thanks to OpenBLT's flexible architecture, new communication interfaces can be added. [[http://www.feaser.com|Feaser]] offers engineering services to add functionality to support any communication interface you desire. For example USB or TCP/IP. It is even possible for OpenBLT to load the new user program image from an SD-card. | Thanks to OpenBLT's flexible architecture, new communication interfaces can be added. [[http://www.feaser.com|Feaser]] offers engineering services to add functionality to support any communication interface you desire. For example USB or TCP/IP. It is even possible for OpenBLT to load the new user program image from an SD-card. | ||
| Line 177: | Line 181: | ||
| **__During a firmware update, is the firmware first downloaded to RAM?__** \\ | **__During a firmware update, is the firmware first downloaded to RAM?__** \\ | ||
| - | Short answer: No. The new firmware is communicated to the bootloader and programmed into flash memory in small chunks of data. Typically 7 to 64 bytes, depending on the used communication interface (CAN, UART, USB, etc). Thanks to this feature, the bootloader can also run on low-end microcontrollers with limited RAM. | + | Short answer: No. The new firmware is communicated to the bootloader and programmed into flash memory in small chunks of data. Typically 7 to 64 bytes, depending on the used communication interface (CAN, RS232, USB, etc). Thanks to this feature, the bootloader can also run on low-end microcontrollers with limited RAM. |
| **__How does a firmware update work?__** \\ | **__How does a firmware update work?__** \\ | ||
| Line 184: | Line 188: | ||
| - The flash memory, which is to be rewritten, is erased. | - The flash memory, which is to be rewritten, is erased. | ||
| - | - The new firmware is communicated to the bootloader and programmed into flash memory in small chunks of data. Typically 7 - 64 bytes, depending on the used communication interface (CAN, UART, USB etc). | + | - The new firmware is communicated to the bootloader and programmed into flash memory in small chunks of data. Typically 7 - 64 bytes, depending on the used communication interface (CAN, RS232, USB etc). |
| - As the last programming step, a checksum value is programmed into flash memory at a fixed location. This is not a checksum of the entire firmware, but typically just a checksum of the vector table. It serves as a marker to determine if the firmware was completely programmed or not. | - As the last programming step, a checksum value is programmed into flash memory at a fixed location. This is not a checksum of the entire firmware, but typically just a checksum of the vector table. It serves as a marker to determine if the firmware was completely programmed or not. | ||
| - Once done, the new software program is started after performing a checksum verification. | - Once done, the new software program is started after performing a checksum verification. | ||
faq.txt ยท Last modified: 2024/02/15 14:43 by voorburg
Page Tools
