User Tools

Site Tools


faq

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
faq [2019/04/18 21:57]
voorburg
faq [2024/02/15 14:43] (current)
voorburg
Line 21: Line 21:
   * On-site integration   * On-site integration
   * Training   * Training
-  * Technical support by phone/e-mail+  * Technical support by e-mail
  
 Feel free to contact [[http://​www.feaser.com|Feaser]] to discuss your support needs. Feel free to contact [[http://​www.feaser.com|Feaser]] to discuss your support needs.
Line 31: Line 31:
 Bootloaders are quite tricky and are critical for the overal functioning and reliability of the system. If the bootloader is not running correctly, it could become impossible to update the user program or, even worse, no longer starts the actual user program once programmed. Bootloaders are quite tricky and are critical for the overal functioning and reliability of the system. If the bootloader is not running correctly, it could become impossible to update the user program or, even worse, no longer starts the actual user program once programmed.
  
-[[https://​www.feaser.com/​en/​services.php|Feaser]] offers professional engineering services to integrate, customize and port OpenBLT to your specific requirements. Feel free to contact Feaser to discuss details and possibilities.+[[https://​www.feaser.com/​en/​services.php|Feaser]] offers professional engineering services to integrate, customize and port OpenBLT to your specific requirements. Feel free to contact Feaser to discuss details and possibilities. If you prefer to give it a try yourself, [[https://​www.feaser.com/​en/​blog/?​p=352|this blog article]] contains detailed instructions on how to adjust the OpenBLT bootloader to your microcontroller system.
  
 **__What licensing options are available?​__** \\  ​ **__What licensing options are available?​__** \\  ​
Line 43: Line 43:
 **__How do I obtain a commercial license for the bootloader?​__** ​ \\  **__How do I obtain a commercial license for the bootloader?​__** ​ \\ 
  
-Contact ​[[http://​www.feaser.com|Feaser]] to request a quote for commercial license. ​Also let them know what type of microcontroller you intend to use, because ​ a commercial license ​is tied to specified microcontroller family (i.e. STM32F1).+Using the [[http://​www.feaser.com/​en/​quote.php|online quote generator]], you can obtain both pricing information and the actual ​quote for your OpenBLT ​commercial license. ​To obtain the commercial license, simply submit ​purchase order to Feaser using the instructions found on the quote.
  
 Note that all revenues generated from commercial licenses is invested back into keeping the OpenBLT project alive. It enables us to spend more time on development and maintenance. Note that all revenues generated from commercial licenses is invested back into keeping the OpenBLT project alive. It enables us to spend more time on development and maintenance.
Line 80: Line 80:
  
 The OpenBLT bootloader already has several security options build-in that can be easily enabled. Together with readily available add-on modules and a few extra configuration steps, your system can be fully secured. Have a look at [[https://​www.feaser.com/​en/​blog/?​p=245|this blog article]], which lists the available security options and explains in detail how to enable them. The OpenBLT bootloader already has several security options build-in that can be easily enabled. Together with readily available add-on modules and a few extra configuration steps, your system can be fully secured. Have a look at [[https://​www.feaser.com/​en/​blog/?​p=245|this blog article]], which lists the available security options and explains in detail how to enable them.
 +
 +**__Can the OpenBLT bootloader update itself?​__** ​ \\ 
 +
 +Yes, this is possible. It involves the creation of a secondary OpenBLT bootloader, derived from the same source code. You can find details and step-by-step instructions in [[https://​www.feaser.com/​en/​blog/​2022/​05/​how-to-update-the-openblt-bootloader-itself/​|this blog article]].
 +
 +Note though that updating the bootloader itself comes with a risk. If something goes wrong during this procedure (for example an unexpected power loss or communication glitch), you might be left with a system that has no bootloader at all.
  
 **__What is the ROM footprint of the bootloader?​__** ​ \\  **__What is the ROM footprint of the bootloader?​__** ​ \\ 
Line 86: Line 92:
  
 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 105:
 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 121:
 **__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 135: Line 145:
 This is where the backdoor entry comes in to save the day. The backdoor allows the bootloader to be entered and activated, regardless of the user program. The default implementation keeps the backdoor open for typically 50ms after reset. Although this time depends on the used communication interface. When a new programming sequence is started with the Microboot download utility, it continuously attempts to establish a connection with OpenBLT. If OpenBLT cannot be reactivated by the user program, simply reset the microcontroller and Microboot automatically connects and activates OpenBLT during the time windows that the backdoor is open. This is where the backdoor entry comes in to save the day. The backdoor allows the bootloader to be entered and activated, regardless of the user program. The default implementation keeps the backdoor open for typically 50ms after reset. Although this time depends on the used communication interface. When a new programming sequence is started with the Microboot download utility, it continuously attempts to establish a connection with OpenBLT. If OpenBLT cannot be reactivated by the user program, simply reset the microcontroller and Microboot automatically connects and activates OpenBLT during the time windows that the backdoor is open.
  
-This implementation is user-friendly and does not depend on any additional hardware. The only downside is that the startup of the user program is always delayed by the backdoor open time window (BOOT_BACKDOOR_ENTRY_TIMEOUT_MS). In case this delay is not acceptable, OpenBLT can be easily reconfigured to allow for an alternative backdoor entry implementation. For example, one that always keeps the bootloader active depending on the state of a digital input upon microcontroller reset. To implement your own backdoor entry through hook functions, change the BOOT_BACKDOOR_HOOKS_ENABLE configurable to 1 in file blt_conf.h.+This implementation is user-friendly and does not depend on any additional hardware. The only downside is that the startup of the user program is always delayed by the backdoor open time window (''​BOOT_BACKDOOR_ENTRY_TIMEOUT_MS''​). In case this delay is not acceptable, OpenBLT can be easily reconfigured to allow for an alternative backdoor entry implementation. For example, one that always keeps the bootloader active depending on the state of a digital input upon microcontroller reset. To implement your own backdoor entry through hook functions, change the ''​BOOT_BACKDOOR_HOOKS_ENABLE'' ​configurable to ''​1'' ​in file blt_conf.h.
  
 **__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 145: Line 155:
 **__How can I disable the assertions?​__** ​ \\  **__How can I disable the assertions?​__** ​ \\ 
  
-By default, both compile-time (ASSERT_CT) and run-time assertions (ASSERT_RT) are enabled. Think of them as safeguards and debugging aids when you are modifying the bootloader. There is nothing wrong with leaving assertions on all the time, as they protect against incorrect configuration and behavior of the bootloader.+By default, both compile-time (''​ASSERT_CT''​) and run-time assertions (''​ASSERT_RT''​) are enabled. Think of them as safeguards and debugging aids when you are modifying the bootloader. There is nothing wrong with leaving assertions on all the time, as they protect against incorrect configuration and behavior of the bootloader.
  
 Some user prefer to differentiate between a debug version and a release version of their bootloader, where the release version disables the assertions. Disabling the assertions in OpenBLT is quite easy. All you have to do is define the **NDEBUG** macro. Ideally, you add it as a compiler flag. With GCC this would be “-DNDEBUG”. Alternatively,​ you can add the following line at the top of assert.h: Some user prefer to differentiate between a debug version and a release version of their bootloader, where the release version disables the assertions. Disabling the assertions in OpenBLT is quite easy. All you have to do is define the **NDEBUG** macro. Ideally, you add it as a compiler flag. With GCC this would be “-DNDEBUG”. Alternatively,​ you can add the following line at the top of assert.h:
  
-<​code>​+<​code ​c>
 #define NDEBUG #define NDEBUG
 </​code>​ </​code>​
Line 161: Line 171:
 **__How can I use 29-bit extended CAN identifiers instead of 11-bit standard?​__** ​ \\  **__How can I use 29-bit extended CAN identifiers instead of 11-bit standard?​__** ​ \\ 
  
-The bootloader uses two CAN identifiers. One for sending command messages from the host and one for receiving response messages. These identifers are configured in blt_confg.h with the macros BOOT_COM_CAN_RX_MSG_ID and BOOT_COM_CAN_TX_MSG_ID,​ respectively. Simply OR the identifier with bitmask 0x80000000 to configure the identifier as 29-bit extended. More details can be found at the bottom of this [[https://​www.feaser.com/​en/​blog/?​p=63|blog article]]. ​+The bootloader uses two CAN identifiers. One for sending command messages from the host and one for receiving response messages. These identifers are configured in blt_confg.h with the macros ​''​BOOT_COM_CAN_RX_MSG_ID'' ​and ''​BOOT_COM_CAN_TX_MSG_ID''​, respectively. Simply OR the identifier with bitmask ​''​0x80000000'' ​to configure the identifier as 29-bit extended. More details can be found at the bottom of this [[https://​www.feaser.com/​en/​blog/?​p=63|blog article]]. ​
  
 **__Can I add functionality for programming an extra non-volatile memory device?​__** ​ \\  **__Can I add functionality for programming an extra non-volatile memory device?​__** ​ \\ 
  
-Yes, absolutely. By default OpenBLT contains a driver to operate on the internal non-volatile memory, which is flash EEPROM in most cases. Through hooks functions that are activated by setting the BOOT_NVM_HOOKS_ENABLE configurable to 1 (blt_conf.h),​ support can be added for 1 or more additional non-volatile memory devices, such as external flash EEPROM and serial EEPROMs. [[http://​www.feaser.com|Feaser]] offers engineering services to add support for additional non-volatile memory devices.+Yes, absolutely. By default OpenBLT contains a driver to operate on the internal non-volatile memory, which is flash EEPROM in most cases. Through hooks functions that are activated by setting the ''​BOOT_NVM_HOOKS_ENABLE'' ​configurable to ''​1'' ​(blt_conf.h),​ support can be added for 1 or more additional non-volatile memory devices, such as external flash EEPROM and serial EEPROMs. 
 + 
 +An in-depth tutorial on how to enabled support for an additional memory device is [[https://​www.feaser.com/​en/​blog/​2024/​02/​additional-memory-device-in-openblt/​|available on the blog]]. For a fully working example, refer to the [[https://​www.feaser.com/​openblt/​doku.php?​id=manual:​demos:​nucleo_l152re_cubeide#​eeprom_memory_device_support|Nucleo-L152RE demo bootloader]]. 
 + 
 +Note that [[http://​www.feaser.com|Feaser]] offers engineering services to develop ​support for additional non-volatile memory devices ​for you.
  
 **__Is the bootloader robust over power failures or loss of communication during firmware updates?​__** ​ \\  **__Is the bootloader robust over power failures or loss of communication during firmware updates?​__** ​ \\ 
Line 173: Line 187:
 **__Can I change the checksum mechanism myself?​__** ​ \\  **__Can I change the checksum mechanism myself?​__** ​ \\ 
  
-By setting the configuration macro BOOT_NVM_CHECKSUM_HOOKS_ENABLE to 1 in blt_conf.h, hook functions become available (NvmWriteChecksumHook() and NvmVerifyChecksumHook()) that allow you to implement your own checksum mechanism. Some customers prefer the checksum to not be just a marker for user program presence, but a checksum over the entire user program. For this, you could add checksum information to the firmware'​s S-record in a post-build step at a fixed (reserved) address, such as the first and last addresses and the actual checksum. The newly available hook functions can then access this checksum information to perform a full checksum verification.+By setting the configuration macro ''​BOOT_NVM_CHECKSUM_HOOKS_ENABLE'' ​to ''​1'' ​in blt_conf.h, hook functions become available (''​NvmWriteChecksumHook()'' ​and ''​NvmVerifyChecksumHook()''​) that allow you to implement your own checksum mechanism. Some customers prefer the checksum to not be just a marker for user program presence, but a checksum over the entire user program. For this, you could add checksum information to the firmware'​s S-record in a post-build step at a fixed (reserved) address, such as the first and last addresses and the actual checksum. The newly available hook functions can then access this checksum information to perform a full checksum verification.
  
 **__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 198:
  
   - 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.1555617461.txt.gz · Last modified: 2019/09/24 22:02 (external edit)