STM32 HID Bootloader: flashing an STM32 over plain USB without drivers

Why a HID bootloader rather than a programmer

The STM32 HID Bootloader is described as a driverless USB HID bootloader and flashing tool for STM32F10X devices, and the summary makes the pitch directly: it is a driverless bootloader, meaning no USB drivers are needed, even on Windows, for STM32F10x and STM32F4xx devices.

That solves a real problem for hobby hardware. The usual way to flash an STM32 is with an ST-Link or a serial programmer, and both need a driver on the host. On Linux the serial route is often fine, on Windows it is a driver hunt, and on macOS it depends on the adapter. A bootloader that presents itself as a USB HID device uses the input drivers every operating system already has, so the board appears as a keyboard-like device and the flashing tool talks to it over HID.

The second decision is what the bootloader does not depend on. It does not use ST libraries since they are bloated and buggy; only CMSIS and some required system files and macros have been used from the ST provided SDK. The payoff is stated in the readme: a very small bootloader, corrected from 4 KB down to 2 KB, on STM32F10x devices. On STM32F4xx devices there is no point making it much smaller than 16 KB, because the first flash page is already 16 KB.

The provenance is stated too. The repository is based on bootsector's stm32-hid-bootloader, but customised to follow the Arduino_Core_STM32 core requirements. That matters because the whole point is that the result works with the Arduino IDE and the STM32duino core.

The project is GPL-2.0 licensed, the primary language is C, and the top-level listing is short: bootloader/ for the firmware, cli/ for the command line tool, pictures/ for the screenshots, and the README and LICENSE.

Installing the bootloader, two ways

There are two procedures in the readme, one for each way of getting the bootloader onto the board in the first place, and both are ten numbered steps.

The ST-Link version starts by downloading the latest HID Bootloader release and the texane stlink tool, extracting it and finding the st-flash file in its bin folder. You then copy the bootloader binary matching your board into that folder, so hid_generic_pc13.bin for a Blue Pill board or hid_maple_mini.bin for a Maple Mini, where the on-board LED is connected to the PC13 pin. Next you connect BOOT-0 and BOOT-1, or the on-board jumpers, to GND, with '0' on the Blue Pill board, and flash the firmware with st-flash.

The Serial Dongle version is the same shape but uses stm32flash from Roger's Clark repository instead of st-flash, sets BOOT-0 to 1, which is 3.3V, and resets the board before writing the bootloader at address 0x8000000.

Both paths then apply the Arduino_STM32_patch from the repository, for the case where you are using Roger's core, with a zip file chosen per operating system. After that you select your board under Tools, then Board, and then select Tools, then Upload method, then HID Bootloader 2.1 or newer. The readme says you are ready at that point.

There is one behavioural detail that catches people out, and it is stated right after the ST-Link steps. Normally both BOOT-0 and BOOT-1 must be connected to 0. If you connect BOOT-1 to 3.3V, or to 1 on Blue Pill boards, the board will stay in HID Bootloader mode. That is the expected behaviour of the bootloader pins, but it looks like a fault if you are not expecting it.

The upstream Arduino method for the STM32 core is HID Bootloader 2.1 or newer, so the version number in that menu entry matters when you pick which bootloader binary to install.

The hid-flash tool and the Linux udev rule

The cli/ folder holds the source for the hid-flash command line tool, and the readme is explicit that the bootloader should not have any compiler restrictions, so it should work with any GCC ARM toolchain version, with the latest always recommended. Building it is just running make in that folder, and the prebuilt hid-flash binary is also included in the latest release.

On Linux there is one extra step, and the readme explains why. To use the HID bootloader without root permissions, a udev rule needs to be installed to /etc/udev/rules.d/99-stm32_hid_bl.rules:

# STM32_HID_bootloader
ATTRS{idProduct}=="beba", ATTRS{idVendor}=="1209", MODE:="666"

The rule matches on the USB vendor and product identifiers, 1209 and beba, and sets the mode so a normal user can write to the device. Without it you would need root to talk to the bootloader. After installing, you might need to reboot or run udevadm control --reload-rules and replug the device to use it as a normal user.

The Windows examples in the readme show the same two-step build for the tool: make clean to clear the previous generated files, then make to create the hid-flash.exe file.

The pairing of a udev rule with an HID interface is what makes the driverless claim work on Linux too. macOS needs no equivalent, since it has a different model for device access, and the readme's list of supported platforms for the tool is Windows, MacOSX and Linux.

Building the bootloader firmware for F1 and F4

The bootloader/ folder contains the source for the hid_bootloader.bin that is burned into the STM32F103 flash memory, and the readme states plainly that currently only the STM32F103 MCU is supported.

That sentence sits slightly awkwardly against the summary, which mentions STM32F4xx devices as well, and the discrepancy is resolved by the build instructions below it. For the STM32F10x build you run make clean to clear the previous generated files and then make generic-pc13, which creates the hid_bootloader.bin with the LED assigned to pin PC13, and you can edit the make_all.bat file to see all supported pin options.

For a High Density Device such as the STM32F103RCT6 you have to add an extra argument to the make command, and the example is make generic-pd2 PAGE_SIZE=2048, which assigns the LED to PD2, with make_all_hd.bat showing the supported pin options for that case. The PAGE_SIZE argument is there because the high density parts have a different flash page geometry, and a bootloader that assumed the wrong page size would not be able to program them.

For STM32F4xx the same pattern applies without a pin argument, make clean then make, and the resulting binary is found at bootloader/F4/build/hid_bootloader.bin. The F4 path is what the summary means when it says there is no point making the bootloader much smaller than 16 KB, because the first flash page is already that size.

The screenshot in the readme is of the Arduino IDE, showing the upload method set to the HID bootloader, which is the workflow the whole project exists to enable.

Where the STM32 HID Bootloader is the wrong choice

The first limitation is the project's own warning. The readme says the software is experimental and a work in progress, and that under no circumstances should these files be used in relation to any critical system, and that use of the files is at your own risk. The full warranty disclaimer follows. That is the right posture for hobby firmware and the wrong posture for anything you would ship, and the difference between the two use cases is exactly the maturity gap.

The second is the device coverage. The bootloader folder section says only the STM32F103 is currently supported, so the STM32F4xx mention in the summary is aspirational or partial, and anyone with an F4 part needs to check what actually exists in the F4 build directory rather than assuming symmetry with F1.

The third is the age of the release line. The published releases are 2.2.1 from June 2019, 2.2.2 from August 2019 and 2.1.0 from June 2019, while the last push to the repository was on 2026-04-27. So there is work in the tree that is not in any tagged release, and the release people actually install from the releases page is several years old.

The fourth is the dependency chain it drags in. The readme's first procedure requires the texane stlink tool, and the second requires stm32flash from a third party's repository. Both are one-time setup steps for the initial flashing, and neither is needed afterwards, but they are steps that can fail for reasons unrelated to this project, and the Arduino_STM32_patch applied afterwards is another moving part.

The fifth is the toolchain and the 2 KB budget. The bootloader is small because it avoids the ST libraries, and small means every byte of the C code matters. That is a good property for the footprint, and it is also why the project's own note that the compiler should not impose restrictions matters, since a toolchain that emits larger code can push the image over the limit.

Editorial conclusion

STM32 HID Bootloader fits a hobbyist or a course instructor who wants students to flash a board without installing a vendor programmer driver on every machine, since the bootloader enumerates as a USB HID device and the Arduino IDE can select HID Bootloader 2.1 or newer as the upload method. It is the wrong choice for production firmware, because the project states it is experimental and a work in progress and warns against using it in any critical system. Before using it, note that the repository currently supports only the STM32F103, that the newest published release is 2.2.2 from 2019-08-30 while the last push was on 2026-04-27, and that on Linux you need the udev rule if you want to flash without root.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. Serasidis/STM32_HID_Bootloader on GitHub