📚 课程目录第1章调试基础

调试基础：嵌入式调试的核心概念、调试器工作原理（JTAG/SWD）、调试环境搭建（OpenOCD + GDB）

嵌入式调试，说白了就是让芯片开口说话。我刚开始做嵌入式那会儿，最原始的办法就是串口打印，满屏的 printf 满天飞。后来遇到一个诡异的内存越界问题，打印根本不管用，程序跑着跑着就飞了。从那以后，我才真正开始研究调试器是怎么工作的。

这一章，咱们把调试的底裤扒开看看。你理解了 JTAG 和 SWD 的本质，后面用 OpenOCD + GDB 的时候就不会觉得是在调黑盒了。

1.1 嵌入式调试的核心概念

调试的本质是什么？是控制和观察。你要能控制 CPU 什么时候停、什么时候跑、单步走哪条指令；同时要能看到寄存器、内存、外设的状态。

调试三要素：

断点（Breakpoint）：让 CPU 在指定地址停下来。硬件断点靠调试模块比较地址总线，软件断点靠插入 BKPT 指令。
单步执行（Step）：一次执行一条指令或一行源码，观察状态变化。
内存/寄存器读写：通过调试接口直接访问目标芯片的内部资源。

这里有个容易混淆的概念——调试接口和调试协议。接口是物理层面的，比如 JTAG 用的 TMS/TCK/TDI/TDO 那几根线；协议是逻辑层面的，比如 ARM 的 CoreSight 调试架构怎么通过 JTAG 扫描链访问 CPU 内部的调试寄存器。

概念	说明	我踩过的坑
硬件断点	由调试模块硬件实现，数量有限（通常 4-8 个）	曾经在循环里设了 10 个断点，结果只有前 4 个生效
软件断点	把指令替换为 BKPT，数量几乎不限	在 Flash 上设软件断点要小心，写 Flash 有寿命限制
Watchpoint	监控某个内存地址的读写操作	用它抓过一个野指针写坏堆栈的 bug，比断点好用

我的习惯：调试初期先用硬件断点，稳定后再切到软件断点。Watchpoint 是排查内存踩踏的神器，很多人不知道用，可惜了。

1.2 调试器工作原理：JTAG 与 SWD

JTAG 最初是给芯片做边界扫描测试用的，后来被 ARM 拿来当调试接口。SWD 是 ARM 后来搞的简化版，只用了两根线（SWDIO 和 SWCLK），在 Cortex-M 系列上非常流行。

1.2.1 JTAG 的工作机制

JTAG 的核心是一个状态机，通过 TMS 信号在 16 个状态之间跳转。每次 TCK 时钟上升沿，状态机根据 TMS 电平决定下一步去哪。数据通过 TDI 串行移入，通过 TDO 串行移出。

为什么会设计成状态机？因为 JTAG 要同时支持边界扫描和调试两种模式。边界扫描时，你要把芯片所有引脚的状态串行读出来；调试时，你要访问 CPU 内部的调试寄存器。状态机通过 IR（指令寄存器）选择当前要操作的数据寄存器（DR），实现模式切换。

// JTAG 状态机核心状态（简化）
// 0: Test-Logic-Reset
// 1: Run-Test/Idle
// 2: Select-DR-Scan
// 3: Capture-DR
// 4: Shift-DR
// 5: Exit1-DR
// 6: Pause-DR
// 7: Exit2-DR
// 8: Update-DR
// 9-15: 对应 IR 路径的类似状态

// 实际调试时，OpenOCD 会帮你管理这些状态
// 你只需要发命令：比如 "halt" 让 CPU 暂停

1.2.2 SWD 的简化设计

SWD 把 JTAG 的 5 根线砍成了 2 根：SWDIO（双向数据线）和 SWCLK（时钟线）。它用包协议代替了状态机，每个操作包含一个请求包和一个响应包。

我记得第一次用 SWD 调试 STM32F103 的时候，发现它比 JTAG 快不少。原因很简单：SWD 的协议开销更小，而且不需要在 TDI/TDO 之间来回切换方向。

特性	JTAG	SWD
引脚数	5（TMS, TCK, TDI, TDO, nTRST）	2（SWDIO, SWCLK）
速度	受限于扫描链长度	通常更快，协议更精简
调试能力	完整，支持边界扫描	仅调试，不支持边界扫描
适用场景	FPGA、复杂 SoC、需要边界扫描	Cortex-M 系列 MCU

注意：SWD 虽然只有两根线，但调试器需要支持双向数据传输。有些便宜的调试器在 SWD 模式下不稳定，我遇到过因为线缆太长导致通信失败的案例。建议 SWD 线缆控制在 15cm 以内。

1.3 调试环境搭建：OpenOCD + GDB

OpenOCD 是开源调试器的瑞士军刀。它负责和硬件调试器（比如 J-Link、ST-Link、FT2232）通信，把 GDB 的调试命令翻译成 JTAG/SWD 协议。GDB 负责提供用户界面，让你设断点、看变量、单步执行。

1.3.1 安装 OpenOCD

我个人习惯在 Linux 下开发，安装很简单：

# Ubuntu/Debian
sudo apt-get install openocd

# 从源码编译（推荐，可以获得最新版本）
git clone https://github.com/openocd-org/openocd.git
cd openocd
./bootstrap
./configure --enable-ftdi --enable-stlink
make -j4
sudo make install

为什么要从源码编译？因为有些调试器需要特定的驱动支持。比如 FT2232 需要 libftdi，ST-Link 需要 libusb。发行版自带的 OpenOCD 可能没开这些选项。

1.3.2 编写 OpenOCD 配置文件

OpenOCD 的配置分三层：接口配置（调试器）、目标配置（芯片）、板级配置（板子上的外设）。

# interface/stlink.cfg - 接口配置
source [find interface/stlink.cfg]
transport select hla_swd  # 使用 SWD 协议

# target/stm32f1x.cfg - 目标配置
source [find target/stm32f1x.cfg]
reset_config srst_only

# 板级配置 - 自定义
adapter speed 1000  # 设置 SWD 时钟为 1MHz
init
targets
halt

启动 OpenOCD：

openocd -f interface/stlink.cfg -f target/stm32f1x.cfg

看到 Info : Listening on port 3333 for gdb connections 就说明成功了。

1.3.3 连接 GDB

另开一个终端，启动 arm-none-eabi-gdb：

arm-none-eabi-gdb your_firmware.elf
(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load
(gdb) continue

这里有个小技巧：我习惯在 GDB 里写一个 .gdbinit 文件，把常用命令放进去：

# .gdbinit
target remote localhost:3333
monitor reset halt
load
break main
continue

避坑指南：我曾经在调试时发现 GDB 连不上 OpenOCD，折腾了半天才发现是防火墙把 3333 端口封了。另外，如果 OpenOCD 报 "Error: unable to find a matching CMSIS-DAP device"，多半是驱动没装好，检查一下 udev 规则。

1.4 本章知识体系

下面这张图把调试的核心脉络串起来了。从调试器硬件到 OpenOCD 再到 GDB，每一层都有明确的职责。

这张图把调试体系分成了四层。最下面是应用场景，上面是具体实现。你从 GDB 发一个 halt 命令，经过 OpenOCD 翻译成 SWD 包，通过调试器硬件送到芯片的 CoreSight 调试模块，最终让 CPU 停下来。每一步都有明确的协议和标准。

本章要点回顾：

调试的核心是控制和观察，断点、单步、内存读写是三大基本操作
JTAG 用状态机实现复杂调试功能，SWD 用包协议简化到 2 根线
OpenOCD 是硬件和 GDB 之间的桥梁，配置分接口、目标、板级三层
GDB + OpenOCD 的组合是嵌入式调试的黄金搭档，免费且强大

嗯，调试基础就这些。你把这些概念吃透了，后面讲 RTOS 调试、低功耗调试、性能分析的时候，就不会觉得底层是黑盒了。调试器说到底就是个工具，理解它的工作原理，你才能用好它。