GDB Debugging Setup
Executive Summary
Debugging embedded firmware with printf is painful. GDB (GNU Debugger) allows you to freeze the processor, inspect memory, walk through code line-by-line, and catch crashes exactly where they happen.
To use GDB with ArduPilot, you need a Hardware Debugger (Blackmagic Probe or ST-Link) and a Debug Build of the firmware.
Theory & Concepts
1. Debug Symbols
By default, the compiler strips variable names and line numbers to save space.
- Flag:
--debug-symbols(or-g). - Result: Generates an
.elffile containing the map between binary machine code and your C++ source lines.
2. Optimization Levels
- Release (
-O2or-Os): The compiler reorders instructions and inlines functions for speed. Stepping through this in GDB is confusing (the cursor jumps around wildly). - Debug (
-O0): No optimization. Code executes exactly as written. Essential for stepping.
Codebase Investigation
1. Waf Configuration
To generate a debug-friendly build:
./waf configure --board=CubeOrange --debug --debug-symbols
./waf copter
This produces build/CubeOrange/bin/arducopter.elf.
2. Connecting the Hardware
- SWD (Serial Wire Debug): The standard ARM debug interface.
- Pins: SWDIO, SWCLK, GND. (VTREF is optional but recommended).
- Port: On a Cube Orange, this is the small "Debug" JST-SH connector next to the USB port.
Source Code Reference
- Waf Options:
wscript(See--debug-symbols)
Practical Guide: The GDB Session
1. Launching GDB
arm-none-eabi-gdb build/CubeOrange/bin/arducopter.elf
2. Connecting (Blackmagic Probe)
target extended-remote /dev/ttyACM0
monitor swdp_scan
attach 1
3. Connecting (ST-Link / OpenOCD)
Start OpenOCD in a separate terminal:
openocd -f interface/stlink.cfg -f target/stm32h7x.cfg
In GDB:
target remote localhost:3333
4. Essential Commands
load: Flashes the firmware (slow, but works).b loop: Set a breakpoint at the main loop.c: Continue execution.bt: Backtrace (Show the call stack - critical for crashes).p var: Print the value of variablevar.