Small USB HID bootloader for BluePill and other STM32F10X devices

[RogerClark]

Found this

https://eligrey.com/demos/FileSaver.js/

https://github.com/eligrey/FileSaver.js

It looks like it can save binary files

[Squonk42]

I just thought of using a text encoding for pins:

• Character 1: port: "A" to "G", "X" for unused pins
• Character 2: bit: in ASCII-encoded hexadecimal: "0" to "9" and "A" to "F", "X" for unused pins
• Character 3: active state: "L" for active low pin, "H" for active-high pin, "X" for unused pins
• Character 4: GPIO mode/cnf: "P" for push-pull output, "O" for open-drain output, "p" for alternate-function push-pull output, "o" for alternate-function open-drain output, "A" for analog input, "F" for floating input, "D" for input with pull-down, "U" for input with pull-up, "X" for unused pins

For example the BP: "B2HFCDHPXXXX"

• B2HF => PB2 is an active-High Floating input pin for the BOOT pin
• CDHP => PC13 (13 dec is hex D) is an active-High Push-pull output for the LED pin
• XXXX => unused pin for the DISC pin

This can be generated using any text editing tool, including a web page containing an embedded JS script that computes this value from pull-down menus as you suggested it.

As for the BL size, we could use a naming convention in the USB descriptor to return the memory description, much like STM's DFUse extension to the standard DFU:
https://github.com/DangerousPrototypes/ ... g/issues/5

For example, a BP with 64 KB Flash, with 2KB HID BL in low-memory:

Code: Select all

@Internal Flash   /0x08000000/2*001Ka,62*001Kg

[Vassilis]

Why is flash size needed, is this for the HIgh Memory version only ?

Yes, this is for the high-memory BL. In the test script I wrote, the user code area size is calculated on-the-fly during the bootloader compiling according to the FLASH_SIZE attribute. The bootloader start address is passed as attribute to the STM32F103.ld file.
Normally, the RAM_SIZE attribute is not needed but is added because the linker script defines the ram size too. The F103 series have from 6 to 96 Kbytes of RAM

Do you need both DISC_EN and DISC_PIN ?
E.g. can you have Disc pin without Disc enable ?

I have two different boards with a different DISC circuits that enable the USB by setting LOW to the DISC pin.
Maybe there are boards that enable the USB with active HIGH. I added the DISC_EN attribute just to cover this case.

[Vassilis]

We could use the 0x0000001C - 0x0000002B to store the pin configuration and configure them at run time rather than fix them during compilation like today, this won't require much code in the BL.

That is interesting !

But then, there is a need for a tool to flash this configuration: it can be by ST-Link or Serial BL, or using a specific sketch, but I don't know how practical this is for a user, any though on this subject is welcome!

Maybe a special attribute to the hid-flash tool could do that job

[Squonk42]

Yes, this is for the high-memory BL. In the test script I wrote, the user code area size is calculated on-the-fly during the bootloader compiling according to the FLASH_SIZE attribute. The bootloader start address is passed as attribute to the STM32F103.ld file.

Right now,the generated assembly code is almost position-independent. All call and branch instructions are PC-relative, non-const data is stored in RAM so not a problem, the only problem is the const data that is accessed relative to the PC, but using useless indirection literal table that store data addresses as absolute values

We could rework the generated assembly source, but it will be a pain to maintain it, as this work will have to be done for each and every version.

I am thinking of a pure C solution that consists in defining all const data (mainly the USB descriptors) into a single structure, and define a pointer to this structure as a non-const (i.e., in RAM) that we will initialize ourself right after boot (since we have no toolchain-generated non-const data automatic initializer at startup). We could then patch this pointer according to our code position in Flash memory and access it indirectly to the right relocated position... This is the solution I am exploring right now.

If this is working, we would only have to generate a single HID bootlader version at an arbitrary location in Flash memory, that will thus relocate its non PC-relative const data itself, and the FLASH_SIZE setting will not be required any more.

Normally, the RAM_SIZE attribute is not needed but is added because the linker script defines the ram size too. The F103 series have from 6 to 96 Kbytes of RAM

The HID bootloader uses less than 6KB anyway, so we definitely don't need it.

I have two different boards with a different DISC circuits that enable the USB by setting LOW to the DISC pin.
Maybe there are boards that enable the USB with active HIGH. I added the DISC_EN attribute just to cover this case.

With my pin encoding described above, you can indeed define the DISC as active LOW or HIGH.

[Squonk42]

OK, I have now an STM32F1 HID bootloader that is fully relocatable, still no assembly required, size is 1960 bytes.

I mean: the same .bin file can be flashed anywhere, you just have to point the reset handler in the Vector Table @ 0x4 to the HID bootloader base address + 1 (for the ARM Thumb flag in the address LSB).

Now I have to figure out how to store and decode the pin configuration, and we will have a single binary STM32F1 HID bootloader file that will handle all pin and memory configurations.

It could then be integrated as a blob into an installer sketch that could burn it at the top of the Flash memory, configure the pins and branch the reset handler to it.

[Vassilis]

Very nice !

[BennehBoy]

If/when the High mem version comes online, can the version be bumped again, and support for the low memory version be left intact in the hid-flash tool?

[Squonk42]

Yes, the version will be bumped, and anyway, the BL will stay in low-memory for the F4, as the high-memory pages are larger.

But for smaller MCUs, the high-memory version would be a nice feature as it will add support for the Cortex M0 CPUs which do not have VTOR registers, provided we can have a single rellocatable binary for all memory and GPIO combinations.

[BennehBoy]

I've got about 20 F1 devices here with hid 3.0 on - I don't want to have to flash them all again