embedded-debugging

Embedded debugging over a debug probe

You are talking to a physical microcontroller through a debug probe. It is slower, more stateful, and far less forgiving than a process on your machine.

The single rule that matters: the device is the source of truth, and it is cheap to ask it. Nearly every wrong answer in this domain comes from reasoning about what the hardware "should" be doing instead of reading it.

Before you debug anything: two files that change everything

Most sessions are needlessly blind because these were never supplied. Check get_config at the start and ask for whichever is missing.

The ELF gives you names

Without it you do not merely lose names — you lose the stack. Measured on an nRF52840, the same halted target, one gdb_load apart:

# no symbols
#0  0x00000048 in ?? ()

# after gdb_load
#0  0x00000048 in rtt_puts (s=s@entry=0x520 "] <") at src/fixture.c:124
#1  0x000001c2 in log_line (level=0x59b "inf", module=0x54a "hil_fixture",
                            msg=0x58d "fixture ready") at src/fixture.c:158
#2  0x000002fa in main () at src/fixture.c:282

One anonymous frame becomes three named ones with arguments and line numbers. GDB cannot unwind past the top frame without the debug info, so "the caller" is not a question you can even ask until the ELF is loaded.

gdb_load { elfFile: "build/zephyr/zephyr.elf" }     # symbols only, does not touch flash

This does not reprogram the device — it loads symbols into GDB. Pass flash: true only when you actually intend to program it. The server halts the target briefly to run it and puts it back, so you do not have to. Load the ELF that matches the firmware currently on the target; a stale ELF gives confidently wrong function names, which is worse than ??.

Once loaded: gdb_backtrace, and gdb_command for info locals, print myStruct, x/16xw &buffer, and turning a faulting address into a line:

info line *0x2a4
Line 91 of "src/fixture.c" starts at address 0x2a4 <main> and ends at 0x2a8 <main+4>.