Flash boot loader

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.

Use

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

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 configure.

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 suffix.

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 hex, bin, srec, list, map, images which creates all of the above, and 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 board TARGET.

Alternatively, if your board isn't defined, you can pick the LED and BUTTON behaviors by setting the Make variables LED, BUTTON and MATRIX. The MATRIX variable specifies a pin to set high before reading the BUTTON pin. The value for all these pins use the specification 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. Negating the MATRIX variable means the pin is set low instead of high before the button pin is read. The resulting build products will be named 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 library lib and 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

1. STLINK_PORT will invoke gdb, trying to connect to stlink via the value of this variable to flash the binary.
2. BMP_PORT will again invoke gdb, this time talking to a Black Magic Probe over the value of this port.
3. OOCD_SERIAL will just use openocd, using the serial port whose value is in this variable. You may want to set the variables OOCD, OOCD_INTERFACE and OOCD_BOARD as well.
4. STM32_PORT will use stm32flash via the serial port whose value is in this variable.
5. Finally, if none of those are set, openocd will be tried using the OOCD, OOCD_BOARD and OOCD_INTERFACE.

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 LED and BUTTON as described above. If it needs a different loader script, set LDSCRIPT for it. In that case, you may want to set APP_ADDRESS as well. Finally, add the name you test against to the BOARDS list.