Hi,
I have successfully put the prebuilt and recompiled versions of toboot on my tomu board. I can then use dfu-util to successfully upload and run any of the im-tomu/tomu-samples examples and the im-tomu/tomu-bootloader/tests/secure-erase/pass-1 test code.

However, on re-applying power to the board (i.e. plugging it back into USB), the toboot bootloader always runs.

Any idea why this is happening? (also, thanks for toboot, it's awesome)

The tomu_flash.conf only flashes the new bootloader. It should clear any application on the board first, then load the new bootloader.

Makes it very hard to tell which mode you are in.

The BOS descriptors are reporting issues on Chrome 68. These should be fixed.

There has been around 20 commits since 2.0-rc7, a new release would be very nice :)

Please don't forget to sign the next release!!

I read following comment:

/// When running a normal program, you won't want Toboot to run.
/// However, when developing new software it is handy to have
/// Toboot run at poweron.  Set this flag to enter Toboot whenever
/// the system has powered on for the first time.
#define TOBOOT_CONFIG_FLAG_AUTORUN_MASK        0x02
#define TOBOOT_CONFIG_FLAG_AUTORUN_SHIFT       1
#define TOBOOT_CONFIG_FLAG_AUTORUN             (1 << 1)

as "if I want to enter toboot on cold boot, I must set config=TOBOOT_CONFIG_FLAG_AUTORUN". But actual behaviour is opposite. I must set config to TOBOOT_CONFIG_FLAG_AUTORUN to disable entering toboot.

Please clarify what is correct behaviour.

The /RESET pin (pin 7 of the MCU) is not made available. This is an issue when working on the bootloader.

Ordinarily, the system relies on being able to send a JTAG reset. This is fine if the MCU isn't locked up. However, if the MCU crashes then it is impossible to reattach gdb without a reset.

In order to develop on the bootloader itself, /RESET should be brought out to a pad.

The bootloader on the SiLabs is the AN0042

• https://www.silabs.com/Support%20Documents/TechnicalDocs/AN0042.pdf
• http://www.silabs.com/Support%20Documents/Software/AN0042SW.zip

We probably want to use this as the basis for our bootloader.

Hey!

Would it be possible to sign future tags? I would make verifying the authenticity of tags much easier and isn't really much more work for you.

Fixing the "ComNav GNSS Receiver" issue

I've had two laptops where the TOMU detected as a "ComNav GNSS Receiver" and would not act as a virtual COM port.

This resolved the issue for me.

1. Leave the TOMU from your USB port

2. Start a CMD prompt, but ensure you run it as administrator. (Press Windows Key, type "cmd", right-click on "Command Prompt" and select "Run as Administrator")

3. In the command prompt, type the following to start device manager with special settings:
   set DEVMGR_SHOW_NONPRESENT_DEVICES=1
   devmgmt.msc

4. From the "view" menu, select "Show hidden Devices"

5. Navigate to "Universal Serial Bus controller", and expand it.

6. Right-click on the "ComNav GNSS Receiver" item and choose properties

7. Go to the "Driver panel", and click on the "Uninstall driver" button

8. Make sure you click the "Delete the driver software for this device" checkbox, then click "Uninstall"

9. From the "Actions" menu, choose "Rescan hardware". Your TOMU, and it should now detect as a "USB Serial Device (COMx)" device, under "Ports (COM & LPT)"

I have a security concern. When using Tomu as U2F device, it storing secret key on flash. Someone with physical access to the Tomu board can easily readout that key. He will need to boot into Toboot, upload malicious firmware which gives away secret key via USB, and then upload U2F firmware back, so that owner wouldn't even notice that secret key is stolen.
SWD can be disabled and it will be impossible to enable it without erasing flash contents. Toboot must also make sure that new firmware cannot be uploaded without erasing the whole application area.
It is also useful to leave few pages which would persist between software updates for the purpose of storing user configuration. These can be part of documented Toboot API. It should also be adviced to not store any sensitive information in this area.

@joshgoes send me some useful pre-built binaries. We should commit them.

The "pin 1" marker for U1 is very subtle, and multiple assembly shops have had trouble identifying it.

"pin 1" should be changed to use the more traditional "pin 1 dot", rather than the current arrangement of a broken box.

Lufa not will be better? http://www.fourwalledcubicle.com/LUFA.php

Currently they talk about the old Silicon Labs bootloader.

Remove / change the d option so that it requires more effort to accidently overwrite the bootloader with something that isn't a bootloader.

The tomu-bootloader repo is licensed (presumably in its entirety) under GPL3. It's not immediately clear what this means for DFU applications that are made compatible with Toboot with the aid of toboot-api.h. It seems exceedingly unlikely that using a single header with some constant and struct definitions would turn an application into a "modified version" of Toboot in the sense of GPL.

Still, it would be clearer if the API header were licensed more permissively, e.g. with an explicit permission that allowed it to be used for making non-GPL applications compatible with toboot.

I was able to flash the bootloader with an STLinkV2, but encountered some issues. I'm exceptionally new to OpenOCD, so it may just be inexperience on my part.

Using OpenOCD and an ST-LinkV2 gives a chip ID error:

Warn : 230 69 hla_interface.c:95 hl_interface_init_target(): UNEXPECTED idcode: 0x0bc11477
Error: 231 69 hla_interface.c:98 hl_interface_init_target(): expected 1 of 1: 0x2ba01477
Debug: 232 69 command.c:628 run_command(): Command failed with error code -4

It seems that the efm32hg309 is not defined and falls through to default (0x2ba01477)
From (tcl/target/efm32.cfg):

if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   set _CPUTAPID 0x2ba01477
}

Using a very recent build of OpenOCD

$openocd --version
Open On-Chip Debugger 0.10.0+dev-00096-gf605a23 (2017-04-07-09:10)

Workaround - Q&D Modify openocd/tomu.conf to define CPUTAPID

-source [find interface/raspberrypi-native.cfg]
-transport select swd
+set CPUTAPID 0x0bc11477

Then this works:
openocd -f interface/stlink-v2.cfg -f ./tomu.conf

Some questions, maybe more OpenOCD related than tomu-bootloader related:
Am I building OpenOCD wrong or is the efm32hg309 just not properly supported?
Perhaps you were doing development with one of the Cortex M3 or M4 which has the chip ID of 0x2ba01477?
Or does transport select swd on the RPi config get the ID right while hla_swd transport supported by STLink somehow get it wrong?

Currently you have to have a short which pulls C high to get into the boot loader.

Other options are;

• Always boot into the boot loader, boot application if not stopped after X seconds.
• Boot into the boot loader when buttons are pressed.
• ????

The DFU bootloader is better in every way;

• It is half the size
• It doesn't need drivers on Windows / Linux / etc
• It's open source
• It compiles with GCC

toboot being a great software using much of it's code from other projects. Some parts like vectors.c look much like borrowed from ChibiOS which is GPLv3. Others, like usb_dev.c look much like taken from https://github.com/im-tomu/chopstx/blob/efm32/mcu/usb-efm32.c which is also GPLv3, but contain wrong attribution for Teensyduino Core Library for some reason. There are parts (mcu.h) copied from Gecko SDK. It pretty much requires toboot to be licensed as GPLv3.

I think it would be great to put COPYING or LICENSE file into the project directory.

There should probably be some documentation, for how to build, flash, and modify the bootloader, maybe about how it works too.

I'll post an issue so that someone better than me at english could fix it.

I think it might be more correct to replace "The EFM32HG has 21 interrupt vectors" with "The EFM32HG has 21 external interrupt vectors".

Referring external interrupt handlers by labels (like VectorN) looks confusing as neither EFM32HG manual nor ARM manual 1 doesn't do that. After some googling I found that it probably comes from ChibiOS where corresponding code was copy-pasted from. Maybe replace labels with offsets or IRQ line numbers?

It would be great to add that in order to implement toboot configuration in Gecko SDK, one must hack on startup_efm32hg.c file and append something like this to the vectors array:

diff --git i/platform/Device/SiliconLabs/EFM32HG/Source/GCC/startup_efm32hg.c w/platform/Device/SiliconLabs/EFM32HG/Sour
ce/GCC/startup_efm32hg.c
index d3eaacee..3714743d 100644
--- i/platform/Device/SiliconLabs/EFM32HG/Source/GCC/startup_efm32hg.c
+++ w/platform/Device/SiliconLabs/EFM32HG/Source/GCC/startup_efm32hg.c
@@ -173,6 +173,8 @@ const pFunc __Vectors[] __attribute__ ((section(".vectors"))) = {
   USART0_TX_IRQHandler,                       /*  18 - USART0_TX       */
   USB_IRQHandler,                       /*  19 - USB       */
   TIMER2_IRQHandler,                       /*  20 - TIMER2       */
+  0x000070b0UL,                            /* toboot cfg flags */
+  0x00046fb0UL,                            /* toboot app flags */
 
 };

README.md doesn't include:

• What to do after dfu-util has completed in the prebuilt directory
• dfu-util usage with prebuilt should be in the first paragraph for "quickstart" instead of down the page
• Should contain what version the firmware "will be"
• Should contain instructions on how to verify the firmware successfully flashed (lsusb or system information on osx)

These would help make the "new user" experience better.

@shenki has apparently started on this...

#53 is my best guess, feel free to fix/improve further

The bootloader cannot boot an application immediately after the bootloader has been flashed and reset. This is a (minor) inconvenience when developing the bootloader.

The problem is that flashing leaves the contents of RAM in an unspecified state with the reset cause SYSREQRST. The bootloader only initializes the boot token when the reset cause is PORST and otherwise assumes that it has valid contents. So what happens is that after flashing the bootloader happily checks the value of boot_count field of the boot token, and this field most probably contains some large value left by the flashing. Hence the application boot is aborted due to BOOT_FAILED_TOO_MANY_TIMES.

To solve this, the bootloader should somehow verify that the boot token contents are valid without depending on the reset cause. Perhaps use some (non-zero) magic value in the magic field of the boot token even when not forcing bootloader entry?

In the setup instructions they say;

sudo cp raspberrypi*-native.cfg /usr/local/share/openocd/scripts/interface/

This is kind of bad. It would be much nicer if you didn't have to do this.

Figure out how to do that!

The bootloader writes new programs to offset 0x2000, meaning it's not possible to update itself.

An updater should be created that can be used to update the updater.

Something goes wrong when the size of an IN control transfer is an exact multiple of the packet size (64 bytes). This is perhaps easiest to test by trying out a string descriptor that is 31 characters long. I haven't investigated exactly what happens, but I suspect that two zero-length packets are sent when only one is mandated.

The easiest way to fix this is to change < to <= in https://github.com/im-tomu/tomu-bootloader/blob/master/toboot/usb_dev.c#L242 but I believe it's also possible to get rid of require_zlp altogether so then the current comparison is correct: the packet is last if it is not full.

Unless I'm missing something, there's also another issue: according to USB 1.1 section 5.5.3, a zero-length packet should not be sent after the last packet, if data_p->len == len_asked, even if the the last packet is full.

Presumably these situations have never come up so far, so they are hardly critical, but they are certainly nasty pitfalls in waiting.