This is a dfu boot loader that runs out of the flash memory, allowing STM32 chips without dfu support in the embedded boot loader to be used as if it had one.
With this flashed, set the CPU BOOT0 pin low to boot from flash memory and run this. If a button is configured and low, then if there is an application flashed at APP_ADDRESS (see below), it will jump to that. Otherwise, it flashes the LED (if configured) to let the user know it's running, and goes high. When dfu loading starts, it will flash the same LED intermittently, finally clearing it when the load is done.
Configuration is done via Make variables. So you'll want to open Makefile in your editor, and read along with these directions.
Configuring the bootloader
At the top of the Makefile is a short set of variables that configure
how the bootloader is built and installed - they'll be covered
later. What you're interested in is the
BOARDS variable below
those. That lists the set of boards that the Makefile knows now to
You can build the bootloader for one of those boards just by doing
make TARGET=*board*. This will name the build
*board*, with all
the various build products using that name with the appropriate
You can also ask for a specific format for the binary by adding it to
the command, as
make TARGET=*board* *format*. Format can be one of
images which creates all of the
flash to flash the binary to your device. That's covered
in more detail later. As a convenience, you can use
make *board* or
make *board*-*format* to build the format binary for for the
Alternatively, if your board isn't defined, you can pick the LED and
BUTTON behaviors by setting the Make variables
MATRIX variable specifies a pin to set high before
BUTTON pin. The value for all these pins use the
P*Port**Pin*, with an optional prefix
- to indicate
negation. Negating the
LED variable means the LED is on when the pin
is low, and vice versa. Negating the
BUTTON variables means means
the button pin is checked for a low value instead of a high one.
MATRIX variable means the pin is set low instead of
high before the button pin is read. The resulting build products will
usbdfu:*LED*+*BUTTON*. The same set of formats can be used,
but there are no convenience targets for these.
Configuring the build process
The variables just below the top comment control the build. There are two that you'll want to set, and one you might want to change.
First, you must set
OPENCM3_DIR to the directory that the libopencm3
include directories reside in.
You can configure the tool you use to flash the bootloader. There are a number of variables you can set to control that. The following are checked in order, and the first one configured will be used. You can always set one on the make command line if you don't always use the same tool
STLINK_PORTwill invoke gdb, trying to connect to
stlinkvia the value of this variable to flash the binary.
BMP_PORTwill again invoke gdb, this time talking to a Black Magic Probe over the value of this port.
OOCD_SERIALwill just use openocd, using the serial port whose value is in this variable. You may want to set the variables
STM32_PORTwill use stm32flash via the serial port whose value is in this variable.
- Finally, if none of those are set, openocd will be tried using
Most of the flash methods were copied intact from the libopencm3 examples, so I haven't tested them.
Adding a board
To add a board, add a case of it in the first set of conditional make
rules in the Makefile, setting
BUTTON as described
above. If it needs a different loader script, set
it. In that case, you may want to set
APP_ADDRESS as well. Finally,
add the name you test against to the