Navigation
External Links
Donate
Show your appreciation for OpenBLT
and support future development by
donating.
External Links
Donate
Show your appreciation for OpenBLT
and support future development by
donating.
This is an old revision of the document!
In order to perform firmware updates with the OpenBLT through the USB communication interface, double-check that this communication interface is configured in “blt_conf.h”. The following macro should have a value of 1. If this macro did not yet have a value of 1, the bootloader should be rebuild after making the change.
#define BOOT_COM_USB_ENABLE (1)
Once the bootloader is programmed and running on your microcontroller system, you will be prompted to install the USB driver, after connecting the system to your PC's USB port. The driver installation is described on a seperate page: OpenBLT USB driver installation instructions.
The Microboot utility needs to be configured to communicate via USB:
Once you saved the settings by clicking the “OK”-button twice, Microboot is now ready for action!
After building your user program, its S-record formatted firmware file can be downloaded to the remaining flash memory using the bootloader. In Microboot click the “Browse”-button and select your user program's firmware file. For the demo programs, this one is located in the “.\Prog\bin\” directory. Once the firmware file was selected, the download should automatically start.
Once the download completed, the newly programmed software will be started by the bootloader. For the demo program's you can verify this by checking that the LED blinks. Congratulations! That's all there is to using the bootloader.
When using USB as the communication interface, it is not recommended to use the default backdoor functionality, which keeps the bootloader active for a short time after reset. In theory it works, however the time that the backdoor stays open should be at least long enough for the installation of the USB driver on the host PC. This is hard to estimate and relatively long, causing long delays between a system reset and the actual starting of the user program.
It is recommended to implement a custom backdoor solution in this case. This is achieved by setting configurable BOOT_BACKDOOR_HOOKS_ENABLE to a value of 1.
#define BOOT_BACKDOOR_HOOKS_ENABLE (1)
You can now implement your own backdoor solution in the hook-functions BackDoorInitHook() and BackDoorEntryHook(). Refer to the demo programs for an example. There, a solution is implemented where the bootloader will always stay active after a reset if a specific digital input had a pre-defined value during reset.