3、软件调试工具：GDB基础、OpenOCD配置、JTAG/SWD调试器使用
调试工具链，说白了就是嵌入式工程师的「听诊器」。没有它，你只能靠LED闪烁猜问题。有了它，你能直接看到CPU内部在干什么。
我刚开始做嵌入式那会儿，还靠串口打印调试。后来遇到一个随机死机的问题，打印语句一加就不死，不加就死——折腾了两周。最后是GDB+JTAG帮我找到了问题：一个未初始化的中断向量表。从那以后，我再也不敢轻视调试工具了。
3.1 GDB基础：不只是「run」和「break」
GDB（GNU Debugger）是嵌入式调试的基石。很多新手觉得GDB就是敲几个命令，其实它的能力远不止这些。
3.1.1 启动GDB的三种方式
| 方式 | 命令 | 适用场景 |
|---|---|---|
| 本地调试 | gdb ./a.out | Linux应用调试，不涉及硬件 |
| 远程调试（核心） | target remote localhost:3333 | 通过OpenOCD连接目标板 |
| 附加进程 | gdb -p PID | 调试正在运行的程序 |
嵌入式调试最常用的是第二种。我个人习惯写一个启动脚本，把target remote、symbol-file、monitor reset这些命令都放进去，省得每次敲。
3.1.2 断点管理——你的「暂停键」
断点不是越多越好。我曾经见过一个同事一口气设了20个断点，结果程序根本跑不动——每个断点都要把Flash指令替换成BKPT指令，开销很大。
# 常用断点命令
break main # 在函数入口设断点
break file.c:42 # 在文件行号设断点
break *0x08001000 # 在绝对地址设断点（硬件断点）
watch my_var # 数据变化时暂停
rwatch my_var # 数据被读取时暂停
info breakpoints # 查看所有断点
delete 1 # 删除编号为1的断点
3.1.3 单步执行——看清每一行代码
单步调试是定位逻辑错误的利器。但要注意：在中断服务函数里单步，很容易触发看门狗复位。我建议先暂停看门狗，或者用monitor halt让CPU停下来再单步。
| 命令 | 作用 | 区别 |
|---|---|---|
step (s) | 单步进入 | 会进入函数内部 |
next (n) | 单步跳过 | 不进入函数，整行执行 |
finish | 执行到函数返回 | 跳出当前函数 |
continue (c) | 继续执行 | 直到下一个断点 |
3.1.4 查看内存与寄存器——看透CPU内部
调试嵌入式程序，光看变量值不够。你得学会看寄存器、看栈、看内存。
# 查看变量和内存
print my_var # 打印变量值
print/x my_var # 十六进制显示
x/16xw 0x20000000 # 查看内存：16个32位字，十六进制
x/10i $pc # 查看当前PC附近的指令
# 查看寄存器
info registers # 所有寄存器
info reg r0 r1 r2 # 指定寄存器
print $lr # 查看链接寄存器（返回地址）
$sp是主栈指针，$psp是进程栈指针。中断里用的是MSP，任务里用的是PSP。搞混了会看到错误的栈回溯。
3.2 OpenOCD配置：桥接主机与目标板
OpenOCD（Open On-Chip Debugger）是连接GDB和调试器硬件的桥梁。它把GDB的抽象命令翻译成JTAG/SWD时序信号。
3.2.1 配置文件结构
一个完整的OpenOCD配置通常包含三部分：接口配置、目标配置、板级配置。我习惯把它们分开写，方便复用。
# interface.cfg —— 调试器接口配置
source [find interface/jlink.cfg]
# 或 source [find interface/stlink.cfg]
# 或 source [find interface/cmsis-dap.cfg]
transport select swd # 选择SWD协议（比JTAG快，只需2根线）
# target.cfg —— 目标芯片配置
source [find target/stm32f4x.cfg]
# 里面定义了：芯片型号、Flash大小、RAM地址、复位方式
# board.cfg —— 板级配置（可选）
# 可以在这里设置时钟、复位策略等
adapter speed 4000 # 设置SWD时钟频率（kHz）
3.2.2 启动OpenOCD
启动命令很简单，但参数顺序有讲究：先接口，再目标，最后是板级配置。
# 基本启动命令
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg
# 带板级配置
openocd -f board/stm32f4discovery.cfg
# 自定义配置
openocd -f my_interface.cfg -f my_target.cfg -f my_board.cfg
启动成功后，你会看到类似这样的输出：
Info : Listening on port 3333 for gdb connections
Info : Listening on port 4444 for telnet connections
Info : Listening on port 6666 for tcl connections
看到3333端口就说明成功了。这时候GDB就可以通过target remote localhost:3333连上来了。
-d参数开启调试日志。遇到连接问题，先看OpenOCD的输出，它比GDB报错信息详细得多。
3.2.3 常见问题与解决
| 问题 | 原因 | 解决方法 |
|---|---|---|
| 连接超时 | SWD时钟太快 | 降低adapter speed到1000kHz以下 |
| 无法识别芯片 | IDCODE不匹配 | 检查target配置中的芯片型号 |
| 复位失败 | 复位引脚被占用 | 改用reset_config srst_only |
| Flash写入错误 | 供电不足 | 检查目标板供电，或降低时钟 |
3.3 JTAG/SWD调试器：选型与使用
调试器是硬件层面的工具。选对了事半功倍，选错了……嗯，我见过有人用山寨J-Link调试工业级产品，结果在高温下频繁断连，排查了三天才发现是调试器的问题。
3.3.1 JTAG vs SWD：怎么选？
| 特性 | JTAG | SWD |
|---|---|---|
| 引脚数 | 4线（TCK/TMS/TDI/TDO） | 2线（SWCLK/SWDIO） |
| 速度 | 最高可达几十MHz | 通常4MHz以内 |
| 链式调试 | 支持（多个芯片串联） | 不支持 |
| 调试能力 | 完整（断点/单步/内存） | 完整 |
| 占用引脚 | 多（至少4个） | 少（2个，可复用） |
| 推荐场景 | FPGA+ARM混合、多核调试 | 绝大多数MCU项目 |
我个人建议：除非你有特殊需求（比如调试FPGA内部的ARM核），否则一律用SWD。省引脚、接线简单、够用。
3.3.2 主流调试器对比
| 调试器 | 接口 | 速度 | 价格 | 特点 |
|---|---|---|---|---|
| J-Link EDU | SWD/JTAG | 最高15MHz | 约400元 | 稳定、软件生态好、支持芯片多 |
| ST-Link/V2 | SWD | 最高4MHz | 约50元 | STM32专用、性价比高 |
| CMSIS-DAP | SWD | 最高10MHz | 约30元 | 开源、ARM官方标准 |
| J-Link PRO | SWD/JTAG | 最高50MHz | 数千元 | 高速、支持多核、工业级 |
3.3.3 接线与信号完整性
SWD只需要4根线：SWCLK、SWDIO、GND、VCC（可选）。但接线质量直接影响调试稳定性。
- 线长：SWCLK和SWDIO的线长不要超过20cm。我见过有人用1米长的杜邦线调试，结果死活连不上。
- 上拉：SWDIO需要上拉（通常10kΩ到VCC），SWCLK需要下拉（10kΩ到GND）。很多开发板已经做了，但自制板要自己加。
- 地线：调试器和目标板必须共地。不要只接信号线不接地，那样信号会乱飘。
- 屏蔽：在强干扰环境（电机驱动、开关电源附近），建议用屏蔽线或双绞线。
3.4 实战：一个完整的调试会话
把前面讲的东西串起来，看一个完整的调试流程。
# 步骤1：启动OpenOCD（终端1）
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg
# 步骤2：启动GDB（终端2）
arm-none-eabi-gdb my_firmware.elf
# 步骤3：在GDB中连接目标板
(gdb) target remote localhost:3333
(gdb) monitor reset halt # 复位并暂停CPU
(gdb) load # 下载固件到Flash
(gdb) break main # 在main函数设断点
(gdb) continue # 运行到main
# 步骤4：开始调试
(gdb) step # 单步进入
(gdb) print/x RCC->AHB1ENR # 查看外设时钟寄存器
(gdb) x/8xw 0x20000000 # 查看SRAM起始内容
(gdb) info registers # 查看寄存器状态
(gdb) backtrace # 查看函数调用栈