Small USB HID bootloader for BluePill and other STM32F10X devices

Generic boards that are not Maple or Maple mini clones, and don't contain the additional USB reset hardware
User avatar
RogerClark
Posts: 8416
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by RogerClark » Wed Feb 06, 2019 9:48 pm


User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Wed Feb 06, 2019 9:56 pm

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

User avatar
Vassilis
Posts: 480
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Vassilis » Wed Feb 06, 2019 11:55 pm

RogerClark wrote:
Wed Feb 06, 2019 8:09 pm
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
RogerClark wrote:
Wed Feb 06, 2019 8:09 pm
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.

User avatar
Vassilis
Posts: 480
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Vassilis » Thu Feb 07, 2019 12:18 am

Squonk42 wrote:
Wed Feb 06, 2019 9:14 pm
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 !
Squonk42 wrote:
Wed Feb 06, 2019 9:14 pm
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

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Thu Feb 07, 2019 6:09 am

Vassilis wrote:
Wed Feb 06, 2019 11:55 pm
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 :cry:

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.
Vassilis wrote:
Wed Feb 06, 2019 11:55 pm
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.
Vassilis wrote:
Wed Feb 06, 2019 11:55 pm
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.

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Fri Feb 08, 2019 11:13 pm

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.

User avatar
Vassilis
Posts: 480
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Vassilis » Sat Feb 09, 2019 8:16 am

Very nice !

User avatar
BennehBoy
Posts: 886
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by BennehBoy » Mon Feb 11, 2019 9:52 am

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?
-------------------------------------
https://github.com/BennehBoy

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 11, 2019 10:09 am

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.

User avatar
BennehBoy
Posts: 886
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by BennehBoy » Mon Feb 11, 2019 1:04 pm

I've got about 20 F1 devices here with hid 3.0 on - I don't want to have to flash them all again :lol:
-------------------------------------
https://github.com/BennehBoy

Post Reply