Flashing ArduPilot on an H7A3-class flight controller

Summary¶

Getting ArduPilot Copter onto an H7A3-class board (Matek H7A3-SLIM and similar) has two paths: a normal .apj flash through Mission Planner or QGroundControl if the board already has an ArduPilot-compatible bootloader, or a DFU flash of the _with_bl.hex file via STM32CubeProgrammer if it's coming from Betaflight/iNav or the normal path fails. This is generic — nothing here is specific to any particular frame or build; it applies to any H7A3-class board going onto ArduPilot for the first time.

Concept¶

Why two paths exist¶

A board shipped new for ArduPilot use, or one that already has an ArduPilot-compatible bootloader from a previous flash, accepts a plain .apj application file over USB — the bootloader is already there to receive it. A board coming from a different firmware family (most commonly Betaflight, since H7A3-SLIM boards are also popular Betaflight targets) may not have that bootloader, and writing an application file with no bootloader present does nothing. The DFU path writes bootloader and application together, which works regardless of the board's prior state — it's the safe default when you're not sure, at the cost of an extra software tool.

Why not flash ArduPilot with Betaflight Configurator¶

Betaflight Configurator's flashing tool is built for STM32 "full chip erase" flows tuned for Betaflight's own build process. On H7-series boards it's known to hang partway through when used to flash a different firmware family. Use STM32CubeProgrammer for the DFU path — it's the tool ArduPilot's own documentation expects, and it doesn't have this failure mode.

Reference¶

Procedure¶

Normal path — board already has an ArduPilot bootloader¶

1. Connect the FC via USB. Select the correct COM port in your ground station (Mission Planner or QGroundControl) but do not connect yet.
2. Mission Planner: Install Firmware → scroll to the bottom → "Load custom firmware" → pick the .apj file.
3. QGroundControl: Vehicle Setup → Firmware → connect the board → Advanced settings → "Custom firmware file" → pick the .apj.
4. Let it flash and reboot. The ground station should reconnect automatically once it's done.

DFU path — board coming from Betaflight/iNav, or normal path failed¶

1. Disconnect USB. Put the board into DFU/bootloader mode — check your specific board's manual for the exact procedure (commonly holding a BOOT button while plugging in USB), since the button or pad location varies by board and manufacturer.
2. Open STM32CubeProgrammer, connect over USB DFU, select @Internal Flash as the target.
3. Flash arducopter_with_bl.hex.
4. Power-cycle. The board should now enumerate as an ArduPilot device — reconnect in your ground station and confirm the firmware version shown matches what you flashed.

If DFU mode won't connect at all¶

Try dfu-util from the command line as a second tool before assuming the board is dead — it succeeds in some cases where STM32CubeProgrammer reports no DFU device. This is a documented pattern on the ArduPilot forums for H7-series boards moved between firmware families, not a guarantee for any specific unit — treat it as a fallback worth trying, not the expected path.

Rationale¶

Two paths exist because "just flash the .apj" is the fast, low-tool-count route that works most of the time, but silently does nothing on a board without the right bootloader — which is exactly the situation anyone moving a board from Betaflight to ArduPilot is in. Documenting the DFU fallback alongside the normal path, rather than only mentioning it as a troubleshooting footnote, means a first-time flash from Betaflight doesn't have to fail once before the builder learns which path they actually needed.

Connections¶

requires: [] related: - ardupilot-copter leads_to: - ardupilot-commissioning