davidgfnet / stm32-dfu-bootloader

A DFU bootloader targeting STM32F103 in just 4KB

STM32F103 DFU bootloader

This is a tiny bootloader (under 4KB) for STM32F103 (although it probably works for similar devices). It enables user to flash devices over USB with any arbitrary payloads. It features some minimal payload checking to ensure use apps are valid before booting them.

Features

• Small size, ideally under 4KB to fit on the first four pages.
• RDP protection configurable at build time.
• Reboot into DFU mode support (by writing tag to RAM + reset).
• Watchdog support for failsafe.
• Total wipe on DFU downloads (avoid partial FW updates).
• Optional upload enable (to prevent firmware/data reads).
• Firmware checksum checking.

Reboot into bootloader

One can reboot into bootloader (in DFU mode) by simply writing the magic 0xDEADBEEFCC00FFEE value to the last 8 bytes of RAM and triggering a full system reset. This will make the bootloader start DFU mode instead of loading the (valid) payload present in flash.

Protections

Bootloader might enable RDP (Readout protection) that will prevent debugger over SWIO from reading data. This protection can be removed but will cause all user flash (except the DFU bootloader) to be deleted, that's cause the first 4KB are always write protected. It can also disable SWIO GPIOs to prevent any debuggers from attaching to the device once booted. The booloader also features some DFU proectections. It is possible to disable firmware read by disabling UPLOAD commands. In order to prevent data read it is possible to prevent partial writes, since what could allow a small firmware being uploaded to extract data from flash. With this protection enabled the bootloader will wipe all the blocks as soon as an erase/write command is issued.

Force DFU mode

The bootloader can be configured to detect a GPIO condition on boot and abort boot to go into DFU mode. The pin will be configured as an internal pulldown and the user will need to pull it up to force DFU mode, which will be read right after reset (there's some small delay to ensure the pin is read correctly).

The firmware can optionally enable the Internal Watchdog on a configurable period of 1 to 26 seconds. If the user app does not reset the watchdog before the period is due it will reset the system and enter DFU mode.

Firmware format and checksum

The use firmware should be build and linked at an offset of 0x1000 (4KB) so it can safely boot as a payload. The bootloader will check some stuff before declaring the payload valid:

• Stack points to somewhere in the RAM range (0x20000000).
• The firmware contains its size at offset 0x20 (as a LE uint32).
• The firmware 32bit XOR checksum is zero (can use offset 0x1C for that).

If these conditions are met, provided no other triggers to boot into DFU are present, the bootloader will point VTOR to the user app and boot it.

Config flags

• ENABLE_DFU_UPLOAD: Enables DFU upload commands, this is, enables reading flash memory (only within the user app boundaries) via DFU.
• ENABLE_SAFEWRITE: Ensures the user flash is completely erased before any DFU write/erase command is executed, to ensure no payloads are written that could lead to user data exfiltration.
• ENABLE_CHECKSUM: Forces the user app image to have a valid checksum to boot it, on failure it will fallback to DFU mode.
• ENABLE_WRITEPROT: Protects the first 4KB of flash against writes. Essentially prevents any user app from overwriting the bootloader area.
• ENABLE_PROTECTIONS: Disables JTAG at startup before jumping to user code and also ensures RDP protection is enabled before booting. It will update option bytes if that is not met and force a reset (should only happen the first time, after that RDP is enabled and can only be disabled via JTAG). This also protects the bootloader (first 4KB) like ENABLE_WRITEPROT does, making these two options incompatible.
• ENABLE_GPIO_DFU_BOOT: Enables DFU mode on pulling up a certain GPIO. You need to define GPIO_DFU_BOOT_PORT and GPIO_DFU_BOOT_PIN to either GPIOA, GPIOB, .. GPIOE and 0 .. 15 to indicate which port to enable and what pin to read from.
• ENABLE_PINRST_DFU_BOOT: Enables DFU mode when a reset from the NRST pin occurs.

By default all flags are set except for DFU upload, so it's most secure.

stm32-dfu-bootloader's Issues

What would it take to modify this to work with STM32H730?

FLASH_BOOTLDR_PAYLOAD_SIZE_KB invalid value

When I tried to compile this project under Windows 10 + MinGW I got an error:

In file included from main.c:19:0:
main.c: In function 'main':
flash_config.h:3:39: error: implicit declaration of function '$' [-Werror=implicit-function-declaration]
#define FLASH_BOOTLDR_PAYLOAD_SIZE_KB $((128 - 4))
^
main.c:401:27: note: in expansion of macro 'FLASH_BOOTLDR_PAYLOAD_SIZE_KB'
imagesize > FLASH_BOOTLDR_PAYLOAD_SIZE_KB*1024/4 ||
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
Makefile:36: recipe for target 'main.o' failed
mingw32-make.exe: *** [main.o] Error 1

which clearly shows, that value of FLASH_BOOTLDR_PAYLOAD_SIZE_KB variable is generated incorrectly.

To circumvent this issue I substituted this line of Makefile:
FLASH_BOOTLDR_PAYLOAD_SIZE_KB = $(shell echo $$(($(FLASH_SIZE) - $(BOOTLOADER_SIZE))))
with this one:
FLASH_BOOTLDR_PAYLOAD_SIZE_KB = ($(FLASH_SIZE) - $(BOOTLOADER_SIZE))

DFU & Interrupts

Hi there, I'm interested in your works which can help me get rid of st-link. However I wonder whether your project supports interrupts mode. I have tried a few dfu bootloaders and both of them didn't support the mode. I have talked to an expert and he said that the code should be reprogrammed NVIC default address to work with the new vector table. Besides, do you mind to compile a .bin file and upload it with some basic instructions? It would be helpful to a beginner like me. Thanks in advance!

missing clock enable for access to AFIO

There is missing AFIO clock enable (RCC_APB2ENR |= 1 << 0;) before AFIO access.

stm32-dfu-bootloader/main.c

Line 439 in cdddd99

*_AFIO_MAPR = (*_AFIO_MAPR & ~(0x7 << 24)) | (0x4 << 24);

Driver and upper computer ?

After I loaded the program onto the chip, the following problems appeared on the computer side:

I want to confirm with you and ask the following questions:

1. Is the upper computer software "dfu-util"?
2. Where can I get the driver for win10 64-bit system?

License

I couldn't find a license specified in the repository.
Would you mind adding licensing information?

Thanks!

application can never boot with undefined `ENABLE_CHECKSUM`

Not defining ENABLE_CHECKSUM causes imagesize = 0.
later follows code...

   	uint32_t xorv = 0xB4DC0FEE;
   	for (unsigned i = 0; i < imagesize; i++) // compiler knows, there will be 0 iterations
   		xorv ^= base_addr[i];

   	if (xorv == 0) { // this branch can never happen with zero iterations of the loop above
   		//... unreachable code, including jump to app
   	}

"checksum" part of code should also be disabled when ENABLE_CHECKSUM is not defined.

How can I send the 0xDEADBEEFCC00FFEE to the stm32?

I was compiled the code, and uploaded to the stm32f103c8t6 controller.
Connected to the PC, device manager can define it as DFU device.
My ST Cube programmer can detect it, named USB1, if the VIDF and PID is matching, but I can't connect it via DFU mode. I have the error: USB Connection lost, can't read data etc.

How can I start to debugging it?

provide how-to erase write locked devices

It's almost impossible to erase device with enabled write protection in bootloader, because you need to change option bytes, then do power cycle and then mass erase. Issues it, after power cycle, bootloader again re-locks write access and erasing is not possible.
The only solution was manual write of magic value into upper 8 bytes of RAM to prevent auto flash write lock and then doing mass erase.

USB device not recognised when starting HID application

Hello,
The bootloader works perfectly and I can confirm that the written data is binary compatible with my firmware.

I also made sure that the linker script was set up accordingly.
checksum.py also reports no problems.

However, when I start my firmware, which acts as a USB-HID device, I get an error:

Windows has stopped this device because it has reported problems. (Code 43)

A request for the USB device descriptor failed.

Everything works perfectly without the bootloader. Any ideas?

This is my project: https://github.com/mupfdev/TrackMAG

Best regards, Michael

Compile and install

Can someone make a tutorial how to compile, i never program Stm32's, only others 8 bits uC can someone tell me how to compile this project?, i'm trying change my 3d printer uC, because my ender 3 v2 have this GD32F and i want change to the Stm32F, and i want the boot-loader to install new firmware using USB

to upgrade an application, i must upgrade it twice

if i want to upgrade an app(app already exists)， i must upgrade it twice.
the first time i program the new app, bootloader only erase flash. before try it again， i must reconnect the device
The second time it was successfully written.

• OS ：windows
• windows application : dfu-util.exe

i can`t fix this , can you help me？ Thank you very much！

Makefile generates invalid "flash_config.h"

When I tried to make project under Windows 10 + MinGW, I got flash_config.h file, that was giving compilation errors due to inclusion of quotes (") simbols at the beginning and at the end of each line of flash_config.h file.
To fix this I edited Makefile to remove quotes from lines which have echo commands under "flash_config.h:" section of Makefile.

i was wondering why this doesn't work with stm32cubeProgrammer

works fine with dfu-util though

hint for bootloader footprint

There is project which implements 1k DFU bootloader, but in different platform (SAMD).
https://github.com/majbthrd/SAMDx1-USB-DFU-Bootloader/blob/master/bootloader.c
With some effort I got it small as 800 bytes.

It shows that actual 4k may potentially be shrinked even more.