Flashing Firmware
"Flashing" replaces the firmware on a board — the flight controller here, though the same idea recurs across the whole open-source stack (ESCs, the radio, the ELRS link). It sounds scary once and then becomes routine maintenance. The discipline that makes it boring: back up first, match the target, fly stable releases.
🟢 Start — the concepts:
- Target = the firmware build for your exact board (e.g. one hex per FC model). The board usually reports its own target when connected; flashing the wrong one is the classic self-inflicted mystery.
- Stable vs release-candidate: fly stable. RCs are for people who enjoy filing bug reports (Module 7 covers the release cadence).
- When to flash at all: a new BNF often ships with old firmware; a used board is an unknown; otherwise flash when a release fixes something you have — not because a number went up.
The flashing flow (flight controller)
diff allin the CLI, save to a file. Non-negotiable (Betaflight basics explains why this text is the whole quad).- Note your current version and target from the top of that diff.
- In the configurator's flasher: pick the target and the latest stable version.
- Put the board in DFU/bootloader mode — usually automatic; if not, hold the boot button while plugging USB in. Props off, obviously; ideally the pack disconnected, USB only.
- Flash. The board reboots as a factory-default Betaflight of the new version.
- Restore selectively. Within the same major version, pasting your diff back is fine. Across a major jump, defaults change on purpose — reapply your settings section by section (ports, failsafe, modes, OSD, rates) rather than pasting a two-versions-old worldview over the new defaults.
- Re-run the bench checks: receiver bars move, modes switch, failsafe drops, motors spin in order (props off).
If the flasher can't see the board in bootloader mode, it's almost always the DFU USB driver. The community's driver-fixer tool (ImpulseRC Driver Fixer) resolves it in one click — this single tip accounts for a remarkable share of "my FC is dead" forum posts.
🟡 Hands-on — the rest of the stack. Every layer flashes separately, on its own schedule, with its own tool (Module 0 has the full table):
| Layer | Tool | Notes |
|---|---|---|
| Flight controller | Betaflight Configurator | This page |
| ESC | esc-configurator.com (Bluejay) / AM32 tools | Per-motor firmware; set direction here, not with the soldering iron |
| ELRS TX & RX | ELRS Configurator / web flasher | TX and RX major.minor must match — ELRS binding |
| Radio | EdgeTX Companion | Back up models to SD first |
The habit that scales: one layer at a time, test between layers. Flashing three things then finding a problem means un-flashing three things to find it.
⚠️ Common mistakes
- Flashing without a saved
diff all. The one mistake you only make once. - Pasting a Betaflight 4.x diff into 5.x wholesale and flying the result.
- "Bricking" panic when it's a DFU driver issue — the hardware is almost never dead.
- Updating everything at once the night before a flying day.
- Chasing every release. Stable + working beats newest, every time.
Where this connects
- Betaflight basics — the configuration you're preserving
- ELRS binding — the version-matching special case
- Module 7 — FC hardware & firmware — targets, boards and what firmware actually is
- Module 8 — Coding the FC — when "flash the release" becomes "flash your own build"