keychron_qmk_firmware/docs/flashing.md
Drashna Jaelre c534a4c775 [Docs] Smallish overhaul of the docs (#5281)
* Fix up Common functions doc

* Add to extra commands to flashing doc

* Rearrange and touch up Macros

* Expand Newbs Flashing guide

* Update process_record documentation

* Add git to best practices name in sidebar

* Expand FAQ for build/flashing

* Add deprecated info to functions

* Update docs/feature_macros.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/feature_macros.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/flashing.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/flashing.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/keymap.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/newbs_flashing.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/newbs_flashing.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/custom_quantum_functions.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/faq_build.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/feature_macros.md

Co-Authored-By: drashna <drashna@live.com>

* Update docs/keymap.md

Co-Authored-By: drashna <drashna@live.com>

* Fix up Common functions doc

* Make pre-init example accurate

* Update docs/custom_quantum_functions.md

Co-Authored-By: drashna <drashna@live.com>

* Zadig Driver catchall

* Spelling Depriciated

* Completely remove fn_actions section
2019-03-18 14:22:02 -07:00

8.3 KiB

Flashing Instructions and Bootloader Information

There are quite a few different types of bootloaders that keyboards use, and just about all of the use a different flashing method. Luckily, projects like the QMK Toolbox aim to be compatible with all the different types without having to think about it much, but this article will describe the different types of bootloaders, and available methods for flashing them.

If you have a bootloader selected with the BOOTLOADER variable in your rules.mk, QMK will automatically calculate if your .hex file is the right size to be flashed to the device, and output the total size in bytes (along with the max). To run this process manually, compile with the target check-size, eg make planck/rev4:default:check-size.

DFU

Atmel's DFU bootloader comes on all atmega32u4 chips by default, 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) (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 your rules.mk (optionally with lufa-dfu or qmk-dfu instead):

# Bootloader
#     This definition is optional, and if your keyboard supports multiple bootloaders of
#     different sizes, comment this out, and the correct address will be loaded
#     automatically (+60). See bootloader.mk for all options.
BOOTLOADER = atmel-dfu

Compatible flashers:

Flashing sequence:

  1. Press the RESET keycode, or tap the RESET button (or short RST to GND).
  2. Wait for the OS to detect the device
  3. Erase the memory (may be done automatically)
  4. Flash a .hex file
  5. Reset the device into application mode (may be done automatically)

or:

make <keyboard>:<keymap>:dfu

QMK DFU

QMK has a fork of the LUFA DFU bootloader that allows for 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, use this block in your config.h (The key that exits the bootloader needs to be hooked-up to the INPUT and OUTPUT defined here):

#define QMK_ESC_OUTPUT F1 // usually COL
#define QMK_ESC_INPUT D5 // usually ROW
#define QMK_LED E6
#define QMK_SPEAKER C6

The Manufacturer and Product names are automatically pulled from your config.h, and "Bootloader" is added to the product.

To generate this bootloader, use the bootloader target, eg make planck/rev4:default:bootloader.

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

DFU commands

There are a number of DFU commands that you can use to flash firmware to a DFU device:

  • :dfu - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
  • :dfu-ee - This flashes an eep file instead of the normal hex. This is uncommon.
  • :dfu-split-left - This flashes the normal firmware, just like the default option (:dfu). However, this also flashes the "Left Side" EEPROM file for split keyboards. This is ideal for Elite C based split keyboards.
  • :dfu-split-right - This flashes the normal firmware, just like the default option (:dfu). However, this also flashes the "Right Side" EEPROM file for split keyboards. This is ideal for Elite C based split keyboards.

Caterina

Arduino boards and their clones use the Caterina bootloader (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like A-Star are based on Caterina.

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

# Bootloader
#     This definition is optional, and if your keyboard supports multiple bootloaders of
#     different sizes, comment this out, and the correct address will be loaded
#     automatically (+60). See bootloader.mk for all options.
BOOTLOADER = caterina

Compatible flashers:

Flashing sequence:

  1. Press the RESET keycode, or short RST to GND quickly (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. Wait for the device to reset automatically

or

make <keyboard>:<keymap>:avrdude

or if you want to flash multiple boards, use the following command

make <keyboard>:<keymap>:avrdude-loop

When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.

Halfkay

Halfkay is a super-slim protocol developed by PJRC that uses HID, and come on all Teensys (namely the 2.0).

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

# Bootloader
#     This definition is optional, and if your keyboard supports multiple bootloaders of
#     different sizes, comment this out, and the correct address will be loaded
#     automatically (+60). See bootloader.mk for all options.
BOOTLOADER = halfkay

Compatible flashers:

Flashing sequence:

  1. Press the RESET keycode, or short RST to GND quickly (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)

STM32

All STM32 chips come preloaded with a factory bootloader that cannot be modified nor deleted. Some STM32 chips have bootloaders that do not come with USB programming (e.g. STM32F103) but the process is still the same.

At the moment, no BOOTLOADER variable is needed on rules.mk for STM32.

Compatible flashers:

Flashing sequence:

  1. Enter the bootloader using any of the following methods:
    • Tap the RESET keycode (may not work on STM32F042 devices)
    • If a reset circuit is present, tap the RESET button
    • Otherwise, you need to bridge BOOT0 to VCC (via BOOT0 button or bridge), short RESET to GND (via RESET button or bridge), and then let go of the BOOT0 bridge
  2. Wait for the OS to detect the device
  3. Flash a .bin file
    • You will receive a warning about the DFU signature; Just ignore it
  4. Reset the device into application mode (may be done automatically)
    • If you are building from command line (e.g. make planck/rev6:default:dfu-util), make sure that :leave is passed to the DFU_ARGS variable inside your rules.mk (e.g. DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave) so that your device resets after flashing

STM32 Commands

There are a number of DFU commands that you can use to flash firmware to a STM32 device:

  • :dfu-util - The default command for flashing to STM32 devices.
  • :dfu-util-wait - This works like the default command, but it gives you a (configurable) 10 second timeout before it attempts to flash the firmware. You can use TIME_DELAY=20 from the command line to change the timeout.
    • Eg: make <keyboard>:<keymap>:dfu-util TIME_DELAY=5
  • :st-link-cli - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util.