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 [2018/08/22 11:26]
voorburg
faq [2020/03/09 12:44] (current)
voorburg
Line 1: Line 1:
 ====== Frequently Asked Questions ====== ====== Frequently Asked Questions ======
 +
 +**__What is the history of the OpenBLT bootloader project?​__** \\  ​
 +
 +The OpenBLT project started out as a hobby project that Frank Voorburg developed on the side in his spare time. Not long after publishing the project as open source at [[https://​sourceforge.net/​projects/​openblt/​|SourceForge]],​ companies contracted him to perform bootloader integrations and customizations for them. 
 +
 +Interest in the OpenBLT project grew consistently and continuously over the following years, resulting in a switch to a [[https://​www.feaser.com/​en/​openblt.php#​licensing|dual licensing model]] and Frank Voorburg reorganizing his company Feaser. Feaser is now fully dedicated to providing professional engineering services and commercial licenses around the OpenBLT bootloader. More details about the history of the OpenBLT project is available in [[https://​www.feaser.com/​en/​blog/?​p=11|this blog article]].
 +
 +One of the main factors contributing to the success of the OpenBLT project is the synergy between the company Feaser on the one hand and the open source OpenBLT project on the other hand. The OpenBLT project generates income for Feaser, which makes it possible for Feaser to fully sponsor the development and maintenance efforts of the OpenBLT project. [[https://​www.feaser.com/​en/​blog/?​p=256|This blog article]] contains more information about the relationship between Feaser and the OpenBLT project.
  
 **__Why should I use the OpenBLT bootloader?​__** \\  ​ **__Why should I use the OpenBLT bootloader?​__** \\  ​
Line 13: 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 23: 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.
  
-[[http://​www.feaser.com|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 35: 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.
 +
 +**__What do I receive after ordering the commercial license?​__** ​ \\ 
 +
 +After submitting your purchase order, Feaser prepares a bootloader package specifically for the microcontroller family that you ordered the commercial license for. It is based on the latest OpenBLT stable release, but all references to the GNU GPL are removed and your commercial license is added as a PDF file. 
 +
 +As an extra service, a demo bootloader and demo user program are added for a microcontroller similar to the one you plan on using. The demo programs can be built with the compiler toolchain that you specified and the demo bootloader is preconfigured for the same firmware update media that you plan on using. Additionally,​ a detailed getting started user manual is added to help you get the bootloader up and running as quickly as possible. The results of the bootloader integration are delivered to you electronically as a zip-archive.
 +
 +Note that Feaser also offers [[https://​www.feaser.com/​en/​services.php|services]] to perform this OpenBLT bootloader integration directly on your hardware.
  
 **__What are the restrictions of the commercial license?​__** ​ \\  **__What are the restrictions of the commercial license?​__** ​ \\ 
Line 49: Line 65:
 No. At this point the commercial license is a one-time fee, so no additional per product royalties have to be paid. No. At this point the commercial license is a one-time fee, so no additional per product royalties have to be paid.
  
-**__What ​do I receive after ordering ​the commercial license?__**  \\ +**__What ​does the bootloader release schedule look like?__**  \\ 
  
-After submitting your purchase orderFeaser prepares a bootloader package specifically for the microcontroller family ​that you ordered the commercial license forIt is based on the latest OpenBLT stable release, but all references to the GNU GPL are removed and your commercial license is added as a PDF file+New stable releases are made twice per year. One in January and one in July. In between these planned releasesit is possible ​that one or more patch releases are madeThis happens when the development of a new feature was completed that users are waiting for or when important bug fixes were made.
  
-As an extra service, a demo bootloader ​and demo user program are added for a microcontroller similar to the one you plan on using. The demo programs ​can be built with the compiler toolchain that you specified and the demo bootloader is preconfigured for the same firmware update media that you plan on usingAdditionally,​ a detailed getting started user manual is added to help you get the bootloader up and running as quick as possibleThe results of the bootloader integration are delivered to you electronically as a zip-archive.+More details about the release schedule and bootloader ​version numbers ​can be found in [[https://​www.feaser.com/​en/​blog/?​p=81|this blog article]].
  
-Note that Feaser also offers [[https://​www.feaser.com/​en/​services.php|services]] to perform this OpenBLT ​bootloader ​integration directly on your hardware.+**__What security options are available in the bootloader?__**  \\ 
  
-**__What does the bootloader ​release schedule look like?​__** ​ \\ +From the context of a bootloader, security options are meant to prevent unwanted third parties from
  
-New stable releases are made twice per yearOne in January and one in July. In between these planned releases, ​it is possible that one or more patch releases are made. This happens when the development of new feature ​was completed that users are waiting for or when important bug fixes were made.+  * Making firmware updates on your product. 
 +  * Capturing your firmware data while it is communicated to your product during ​firmware update. 
 +  * Reading out your firmware data after it was programmed onto your product.
  
-More details about the release schedule and bootloader ​version numbers ​can be found in [[https://​www.feaser.com/​en/​blog/?​p=81|this blog article]].+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.
  
 **__What is the ROM footprint of the bootloader?​__** ​ \\  **__What is the ROM footprint of the bootloader?​__** ​ \\ 
Line 68: 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 77: 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 84: Line 106:
  
 Although we highly recommend the XCP protocol, it is definitely possible to replace it with another communication protocol, thanks to the bootloader’s [[manual:​design#​modules|modular architecture]]. Although we highly recommend the XCP protocol, it is definitely possible to replace it with another communication protocol, thanks to the bootloader’s [[manual:​design#​modules|modular architecture]].
- 
- 
  
 **__Can I exchange data between the bootloader and my firmware?​__** ​ \\  **__Can I exchange data between the bootloader and my firmware?​__** ​ \\ 
Line 95: 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?​__** ​ \\ 
  
 At the end of a programming session, the bootloader stores a program specific 32-bit checksum in non-volatile memory. When the bootloader is about to start the user program, this checksum is first verified and based on the results of this verification,​ the bootloader determines if it's safe to start the user program. At the end of a programming session, the bootloader stores a program specific 32-bit checksum in non-volatile memory. When the bootloader is about to start the user program, this checksum is first verified and based on the results of this verification,​ the bootloader determines if it's safe to start the user program.
 +
 +Note that this 32-bit checksum is calculated over only a small portion of your software program, typically a part of the interrupt vector table. It is meant as a signature that helps the bootloader to determine if a software program is present or not. To have a checksum verification over the entire contents of your software program, Feaser offers the [[https://​www.feaser.com/​en/​addons.php#​checksum|improved checksum]] add-on module.
  
 **__How do I debug my own firmware, when the bootloader is also present in flash?​__** ​ \\  **__How do I debug my own firmware, when the bootloader is also present in flash?​__** ​ \\ 
  
-If your embedded system makes use of the OpenBLT bootloader, then essentially you have two software programs present in flash memory: your own firmware and the OpenBLT bootloader. This added complexity can cause a problem when trying to debug your firmware. With a few small workarounds,​ you can get full debug functionality back for your firmware. A detailed explanation on how to accomplish this can be found on the [[https://​www.feaser.com/​en/​blog/?​p=35|developer blog]].+If your embedded system makes use of the OpenBLT bootloader, then essentially you have two software programs present in flash memory: your own firmware and the OpenBLT bootloader. This added complexity can cause a problem when trying to debug your firmware.  
 + 
 +The OpenBLT bootloader writes a 32-bit checksum to flash memory at the end of the firmware update. It is used as a signature to determine if firmware is present or not. When programming your firmware with the debugger instead, this checksum value does not get written, resulting in the bootloader not starting your firmware during a debug session. 
 + 
 +A simple workaround is to program your firmware with the OpenBLT bootloader, so using the MicroBoot and/or BootCommander PC tool. Then in your integrated development environment you can configure your debugger session such that it does not flash code, but only loads debugger symbols. 
 + 
 +The downside of this approach is that there is an extra step involved each time you start a debug session. Additionally,​ flashing your firmware with the debugger is typically quicker that using a bootloader. With a few small workarounds,​ you can get full debug functionality back for your firmware. A detailed explanation on how to accomplish this can be found on the [[https://​www.feaser.com/​en/​blog/?​p=35|developer blog]].
  
 **__What is the backdoor entry?​__** ​ \\  **__What is the backdoor entry?​__** ​ \\ 
Line 115: 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 153: 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 160: 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.1534930010.txt.gz · Last modified: 2019/09/24 22:02 (external edit)