MAVLINKHUD

Updating Firmware via OpenOCD

While Cloning captures the entire state of a flight controller (2MB), a standard Firmware Update only overwrites the code itself. This guide explains how to use OpenOCD to flash new ArduPilot builds while ensuring your hard-earned calibrations and parameters ("User Data") remain untouched.

1. Generating the Firmware (The Build)

Before you can flash, you must compile the ArduPilot source code for your specific hardware. ArduPilot uses the Waf build system.

1.1 Configure the Board

First, tell the build system which board you are using. For the MicoAir 743, use the following command from the root of the ardupilot directory:

# Configuration for MicoAir 743
./waf configure --board MicoAir743

Note: You only need to run this once, or whenever you change board types.

1.2 Compile the Binary

Next, run the build command for your vehicle type (Plane, Copter, Rover, etc.):

# Build ArduPlane
./waf plane

# Or for ArduCopter:
# ./waf copter

1.3 Locate the Artifacts

Once the build completes, your files will be located in:
build/MicoAir743/bin/

For OpenOCD flashing, we specifically want the arduplane_with_bl.hex file. This version includes the ArduPilot bootloader, making it "self-healing" if the board's existing bootloader is missing or corrupted.

2. The Distinction: Updates vs. Cloning

It is vital to understand what happens to your memory during different operations:

Operation File Type Data Covered Effect on Parameters
Cloning .bin (2MB) 100% of Flash Overwrites All (Resets to Master)
Updating .hex (~4MB) ~60% of Flash Preserves User Data

Why is the .hex file so big?

You may notice that arduplane_with_bl.hex is roughly 4MB, which is larger than the 2MB physical capacity of the chip. This is normal. The Intel HEX format is a text-based encoding. Every 1 byte of binary data is represented by multiple ASCII characters. When OpenOCD flashes the file, it extracts the ~1.4MB of binary data and ignores the text overhead.

2. Why User Data is Safe

ArduPilot allocates specific sectors at the very end of the flash memory for parameter storage (User Data).

  • Firmware Range: Typically 0x08000000 to 0x08160000.
  • User Data Range: Typically 0x081FE000 to 0x081FFFFF.

Because OpenOCD's program command is sector-aware, it only erases the areas where the firmware has data. Since the firmware binary does not reach the final sectors of the chip, your calibrations are never touched.

3. The "1MB Border" Requirement

Even though we are not dumping the full 2MB, the manual bank definition is still required for the H743.

ArduPilot firmware for the H7 is usually ~1.3MB. This means the code starts in Bank 0 but "crosses the border" into Bank 1 at the 1024KB mark. If you do not define bank1, OpenOCD will crash the moment it tries to write the 1,024,001st byte.

4. The Update Command

Use this command to update your firmware. Note that we do not provide a start address (0x08000000) at the end because .hex files have their own target addresses built-in.

# Manual Bank Definition is still required to cross the 1MB boundary
openocd \
  -f interface/stlink.cfg \
  -f target/stm32h7x.cfg \
  -c "flash bank bank1 stm32h7x 0x08100000 0x100000 0 0 stm32h7x.cpu0" \
  -c "init; program arduplane_with_bl.hex verify reset exit"

Success Indicators:

  1. Device Info: "flash size probed value 2048k".
  2. Programming Started: OpenOCD will report "Device: STM32H74x/75x".
  3. Verified OK: The new code is verified.
  4. Reset: The board reboots and your parameters are still there.

5. When to use .apj vs .hex

  • Mission Planner / QGC: Use the .apj file. It contains metadata for the GCS.
  • OpenOCD / ST-Link: Use the _with_bl.hex file. It includes the bootloader, ensuring the board can start even if the previous firmware was corrupted.

Related Intelligence

Cloning Flight Controllers