An updated version of gboot available here
gboot is a very simple USB HID bootloader for Silicon Laboratories USB microcontrollers. It has been developed for C8051F320/1 but it should work, after a few trivial modification, on other Silicon Laboratories USB MCUs.
The main advantages of a HID bootloader versus other types of USB bootloaders is that HID does not require any third party kernel driver as the basic HID driver is included in all modern operating systems.
Currently there are 2 version of the bootloader depending on the features and the space available. The tiny build fits in less than 1.5k (3 flash blocks) and the standard build is less than 2k (4 flash blocks).
gboot can only be compiled using SDCC, but this does not limit the use of other compilers for the firmware.
A small command line flashing utility called gflash is available for windows and linux. A GUI version of the flasher is planned.
gboot is open source and it is licensed under the GNU GPL V3. Other licensing schemes are available email us for details.
Features
- return basic information about the device and flash layout
- erase a flash page
- write to flash
- read flash
- prevent write/erase of the bootloader code
- detect HW button for firmware recovery
- reboot the MCU
Flashing gboot
For the initial bootloader installation you must use Silicon Labs IDE or the flasher. I was not able to get any of the free tools (ec2drv or ec2drv-new) to work with my Silabs toolstick. It seems that the firmware of the toolstick is incompatible with the ec2drv.
If you find a solution/alternative please contact me.
Preparing your firmware for use with gboot
Build your firmware with the extra link option --code-loc 0x0400.
This will instruct the linker to skip the first 1024 bytes of flash as they are occupied by the bootloader.
Convert the intel hex file to binary using srec_cat, hex2bin or your favourite tool (making sure the code starts at offset 0 in the bin file).
Flashing the firmware
Flashing the firmware it's pretty easy using gflash:
gflash_cli p file.bin
gflash_cli b
To Do
- Enhance/document the firmware/bootloader interface
- investigate further code size reductions
- add Silabs C8051F34x and C8051F38x support out of the box
USB-IF Testsuite reports
| Attachment | Size |
|---|---|
| gboot-0.2-rc1.tar.gz | 81.41 KB |
| gflash-0.2-rc1.tar.gz | 100.85 KB |
| gflash_cli windows binary | 62.01 KB |
Not quite right
I've followed the instructions here to load both the standard and tiny bootloaders using the silabs flash utility. This step works great - Windows (7 x64) recognizes the mcu (8051F340) and I can run "gflash_cli i" and "gflash_cli b" without issue. However, when I run "gflash_cli p foo.bin" I consistently get "verifying flash error at offset 0400" "expected: 32 read:00". I'm using "hex2bin foo.hex" to create the .bin file. Strangely, once I power cycle the board, my program starts running but there's no indication that the bootloader is still there. Is this normal? I notice that the bootlader is listed as occupying either 1.5k or 2k of flash, yet the offset to the linker is only 1k. Is the bootloader being overwritten (even though it's supposedly protected)? Thanks for the tool.
Thanks for the comment.
Thanks for the comment. The firmware uses the first 1k + the last 0.5 or 1k (depending on the tiny vs. regular build). The bootloader is split because it must use the first page for the interrupt vectors and must use the last page since it can only be flashed using the debug interface.
If your application runs the bootloader is most likely still there. The simplest way to enter the bootloader is to short P3_0 (not P0_3 as stated previously) to GND during poweron or hardware reset.
I checked the issue you reported and I root caused it to a known issue with the libusb version I used to link the windows binary. Please try the new version I just uploaded.
Finally, the bootloader should be recompiled for the F340 to reflect the increased amount of flash vs. the F320.
Fixed!
It looks like your change to gflash fixed the issue. I no longer receive the error after flashing through USB.
I hadn't looked at the code enough to see that shorting the pin to ground was how you enter the bootloader on startup. This works fine. One note: the comments in the code are correct, but users should be aware that gboot is looking for a short on P3_0, not P0_3 as in your last comment.
I haven't taken the time to recompile for the 340 yet but I'll let you know if I run into any issues in the future. Thanks again, this is a very useful utility.