import { _ as _export_sfc, c as createElementBlock, o as openBlock, a8 as createStaticVNode } from "./chunks/framework.B9AX-CPi.js"; const __pageData = JSON.parse('{"title":"Flashing Instructions and Bootloader Information","description":"","frontmatter":{},"headers":[],"relativePath":"flashing.md","filePath":"flashing.md"}'); const _sfc_main = { name: "flashing.md" }; const _hoisted_1 = /* @__PURE__ */ createStaticVNode('

Flashing Instructions and Bootloader Information ​

There are quite a few different types of bootloaders that keyboards use, and almost all of them use their own flashing method and tools. Luckily, projects like the QMK Toolbox aim to support as many of them as possible, but this article will describe the different types of bootloaders, and available methods for flashing them.

For AVR-based keyboards, QMK will automatically calculate if your .hex file is the right size to be flashed to the device based on the BOOTLOADER value set in rules.mk, and output the total size in bytes (along with the max).

You will also be able to use the CLI to flash your keyboard, by running:

$ qmk flash -kb <keyboard> -km <keymap>

See the qmk flash documentation for more information.

Atmel DFU ​

Atmel's DFU bootloader comes on all USB AVRs by default (except for 16/32U4RC), and is used by many keyboards that have their own ICs on their PCBs (older OLKB boards, Clueboards). Some keyboards may also use LUFA's DFU bootloader, or QMK's fork of it (newer OLKB boards), that adds in additional features specific to that hardware.

To ensure compatibility with the DFU bootloader, make sure this block is present in your rules.mk (optionally with lufa-dfu or qmk-dfu instead):

make
# Bootloader selection\nBOOTLOADER = atmel-dfu

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Erase the flash memory (will be done automatically if using the Toolbox or CLI/make command)
  4. Flash a .hex file
  5. Reset the device into application mode (will be done automatically as above)

QMK DFU ​

QMK maintains a fork of the LUFA DFU bootloader that additionally performs a simple matrix scan for exiting the bootloader and returning to the application, as well as flashing an LED/making a ticking noise with a speaker when things are happening. To enable these features, add the following defines to your config.h:

c
#define QMK_ESC_OUTPUT F1  // COL pin if COL2ROW\n#define QMK_ESC_INPUT  D5  // ROW pin if COL2ROW\n// Optional:\n//#define QMK_LED E6\n//#define QMK_SPEAKER C6

Currently we do not recommend making QMK_ESC the same key as the one designated for Bootmagic, as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.

The manufacturer and product strings are automatically pulled from config.h, with " Bootloader" appended to the product string.

To generate this bootloader, use the bootloader target, eg. make planck/rev4:default:bootloader. To generate a production-ready .hex file (combining QMK and the bootloader), use the production target, eg. make planck/rev4:default:production.

make Targets ​

Caterina ​

Arduino boards and their clones use the Caterina bootloader or a variant of it (any keyboard built with a Pro Micro or clone, and the Pololu A-Star), and uses the AVR109 protocol to communicate through virtual serial.

To ensure compatibility with the Caterina bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = caterina

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods (you only have 7 seconds to flash once it enters; some variants may require you to reset twice within 750 milliseconds):
  2. Wait for the OS to detect the device
  3. Flash a .hex file
  4. Wait for the device to reset automatically

make Targets ​

HalfKay ​

HalfKay is a super-slim bootloader developed by PJRC that presents itself as an HID device (which requires no additional driver), and comes preflashed on all Teensys, namely the 2.0. It is currently closed-source, and thus once overwritten (eg. via ISP flashing another bootloader), cannot be restored.

To ensure compatibility with the Halfkay bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = halfkay

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods (you only have 7 seconds to flash once it enters):
  2. Wait for the OS to detect the device
  3. Flash a .hex file
  4. Reset the device into application mode (may be done automatically)

USBasploader ​

USBasploader is a bootloader originally by Objective Development. It emulates a USBasp ISP programmer and is used in some non-USB AVR chips such as the ATmega328P, which run V-USB.

To ensure compatibility with the USBasploader bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = usbasploader

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .hex file
  4. Press the RESET button on the PCB or short RST to GND

BootloadHID ​

BootloadHID is a USB bootloader for AVR microcontrollers. It presents itself as an HID input device, much like HalfKay, and can therefore be run without installing any driver on Windows.

To ensure compatibility with the bootloadHID bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = bootloadhid

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .hex file
  4. Reset the device into application mode (may be done automatically)

QMK HID ​

QMK maintains a fork of the LUFA HID bootloader, which uses a USB HID Endpoint for flashing in the way that the PJRC's Teensy Loader flasher and HalfKay bootloader work. Additionally, it performs a simple matrix scan for exiting the bootloader and returning to the application, as well as flashing an LED/making a ticking noise with a speaker when things are happening.

To ensure compatibility with the QMK HID bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = qmk-hid

To enable the additional features, add the following defines to your config.h:

c
#define QMK_ESC_OUTPUT F1  // COL pin if COL2ROW\n#define QMK_ESC_INPUT  D5  // ROW pin if COL2ROW\n// Optional:\n//#define QMK_LED E6\n//#define QMK_SPEAKER C6

Currently we do not recommend making QMK_ESC the same key as the one designated for Bootmagic, as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.

The manufacturer and product strings are automatically pulled from config.h, with " Bootloader" appended to the product string.

To generate this bootloader, use the bootloader target, eg. make planck/rev4:default:bootloader. To generate a production-ready .hex file (combining QMK and the bootloader), use the production target, eg. make planck/rev4:default:production.

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .hex file
  4. Reset the device into application mode (may be done automatically)

make Targets ​

STM32/APM32 DFU ​

All USB-capable STM32 and APM32 MCUs, except for a small handful (such as STM32F103 -- see the STM32duino section) come preloaded with a factory bootloader that cannot be modified nor deleted.

To ensure compatibility with the STM32-DFU bootloader, make sure this block is present in your rules.mk (optionally with apm32-dfu instead):

make
# Bootloader selection\nBOOTLOADER = stm32-dfu

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .bin file
  4. Reset the device into application mode (may be done automatically)

make Targets ​

STM32duino ​

This bootloader is used almost exclusively for STM32F103 boards, as they do not come with a USB DFU bootloader. The source code and prebuilt binaries can be found here.

To ensure compatibility with the STM32duino bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = stm32duino

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .bin file
  4. Reset the device into application mode (may be done automatically)

Kiibohd DFU ​

Keyboards produced by Input Club use NXP Kinetis microcontrollers rather than STM32, and come with their own custom bootloader, however the process and protocol is largely the same.

The rules.mk setting for this bootloader is kiibohd, but since this bootloader is limited to Input Club boards, it should not be necessary to set at keymap or user level.

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .bin file
  4. Reset the device into application mode (may be done automatically)

WB32 DFU ​

Some keyboards produced for several commercial brands (GMMK, Akko, MonsGeek, Inland) use this bootloader. The wb32-dfu-updater utility is bundled with QMK MSYS and Glorious's build of QMK Toolbox. If neither of these flashing methods is available for your OS, you will likely need to compile the CLI version from source.

The info.json setting for this bootloader is wb32-dfu.

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash a .bin file
  4. Reset the device into application mode (may be done automatically)

tinyuf2 ​

Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on F303/F401/F411.

The rules.mk setting for this bootloader is tinyuf2, and can be specified at the keymap or user level.

To ensure compatibility with the tinyuf2 bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = tinyuf2

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Copy the .uf2 file to the new USB disk
  4. Wait for the keyboard to become available

or

CLI Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash via QMK CLI eg. qmk flash --keyboard handwired/onekey/blackpill_f411_tinyuf2 --keymap default
  4. Wait for the keyboard to become available

make Targets ​

uf2boot ​

Keyboards may opt into supporting the uf2boot bootloader. This is currently only supported on F103.

The rules.mk setting for this bootloader is uf2boot, and can be specified at the keymap or user level.

To ensure compatibility with the uf2boot bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = uf2boot

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Copy the .uf2 file to the new USB disk
  4. Wait for the keyboard to become available

or

CLI Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash via QMK CLI eg. qmk flash --keyboard handwired/onekey/bluepill_uf2boot --keymap default
  4. Wait for the keyboard to become available

make Targets ​

Raspberry Pi RP2040 UF2 ​

The rules.mk setting for this bootloader is rp2040, and can be specified at the keymap or user level.

To ensure compatibility with the rp2040 bootloader, make sure this block is present in your rules.mk:

make
# Bootloader selection\nBOOTLOADER = rp2040

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Copy the .uf2 file to the new USB disk
  4. Wait for the keyboard to become available

or

CLI Flashing sequence:

  1. Enter the bootloader using any of the following methods:
  2. Wait for the OS to detect the device
  3. Flash via QMK CLI eg. qmk flash --keyboard handwired/onekey/rpi_pico --keymap default
  4. Wait for the keyboard to become available

1: This works only if the controller has been flashed with QMK Firmware with RP2040_BOOTLOADER_DOUBLE_TAP_RESET defined.

', 143); const _hoisted_144 = [ _hoisted_1 ]; function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) { return openBlock(), createElementBlock("div", null, _hoisted_144); } const flashing = /* @__PURE__ */ _export_sfc(_sfc_main, [["render", _sfc_render]]); export { __pageData, flashing as default };