第二章 调试工具链搭建：J-Link/ST-Link驱动安装、OpenOCD配置、GDB调试器入门
调试工具链，说白了就是你和MCU之间的“翻译官”。没有它，你写的代码烧进去到底跑没跑、跑到哪了，全靠猜。我刚入行那会儿，有次一个中断死活不触发，折腾了两天，最后发现是调试器没装对驱动——这种坑，踩过一次就记住了。
这一章，咱们把工具链从头捋一遍。J-Link、ST-Link怎么装驱动，OpenOCD怎么配，GDB怎么用。这些东西配好了，后面调试才能顺手。
2.1 调试器驱动安装
调试器分两种主流：J-Link（SEGGER家的）和ST-Link（ST原厂的）。驱动装不对，设备管理器里就是黄叹号，连不上目标板。
2.1.1 J-Link驱动
去SEGGER官网下载“J-Link Software and Documentation Pack”。装完以后，设备管理器里能看到“J-Link driver”或者“J-Link CDC UART Port”。
验证驱动是否正常，插上J-Link，打开命令行敲：
JLinkExe
如果能弹出J-Link命令行界面，说明驱动OK。我遇到过一种情况：插上后灯亮，但JLinkExe报“No J-Link found”。后来发现是USB线太长，信号衰减了——换根短线搞定。
2.1.2 ST-Link驱动
ST-Link分V2和V3。V2最常见，装ST官方工具链“STM32CubeProgrammer”或者“ST-Link Utility”就能自动装好驱动。V3需要单独装“ST-Link V3 driver”。
验证方法：插上ST-Link，设备管理器里看到“STMicroelectronics STLink dongle”就对了。如果显示“ST-Link/V2-1”，说明驱动OK，还能当虚拟串口用。
2.2 OpenOCD配置
OpenOCD（Open On-Chip Debugger）是个开源调试工具，支持J-Link、ST-Link、FTDI等各种调试器。它的核心是配置文件——告诉OpenOCD你用的是什么调试器、什么目标芯片。
2.2.1 安装OpenOCD
Windows用户去官网下载预编译包，解压到C:\OpenOCD。Linux用户直接apt或yum装：
sudo apt install openocd
装完验证：
openocd --version
能显示版本号就行。我习惯把OpenOCD的bin目录加到系统PATH里，这样命令行随时能调。
2.2.2 配置文件结构
OpenOCD的配置文件分两部分：
- 接口配置（interface）：定义调试器类型，比如J-Link、ST-Link
- 目标配置（target）：定义芯片型号，比如STM32F103、STM32F407
一个典型的启动命令长这样：
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg
这里-f后面跟的是配置文件路径。OpenOCD自带的配置文件在openocd/scripts/目录下。
2.2.3 常用配置示例
| 调试器 | 接口配置文件 | 目标芯片 | 目标配置文件 |
|---|---|---|---|
| J-Link | interface/jlink.cfg | STM32F103 | target/stm32f1x.cfg |
| ST-Link/V2 | interface/stlink.cfg | STM32F407 | target/stm32f4x.cfg |
| FTDI | interface/ftdi/xxx.cfg | NXP LPC1768 | target/lpc17xx.cfg |
如果你用的是自定义板子，可以自己写配置文件。举个例子，我有个项目用J-Link调试STM32F103，配置文件长这样：
# my_board.cfg
source [find interface/jlink.cfg]
source [find target/stm32f1x.cfg]
# 自定义SWD速度
adapter speed 1000
然后启动：
openocd -f my_board.cfg
2.3 GDB调试器入门
GDB（GNU Debugger）是命令行调试器，配合OpenOCD用，能实现断点、单步、查看变量、反汇编等操作。很多人觉得命令行不如IDE方便，但说实话，GDB在排查疑难杂症时比IDE灵活得多。
2.3.1 启动GDB
先启动OpenOCD，让它监听端口（默认3333）。然后另开一个终端，启动GDB：
arm-none-eabi-gdb my_firmware.elf
在GDB里连接OpenOCD：
(gdb) target remote localhost:3333
连上以后，GDB会停在芯片复位后的第一条指令。这时候你就可以开始调试了。
2.3.2 常用GDB命令
| 命令 | 作用 | 示例 |
|---|---|---|
load |
下载固件到目标板 | (gdb) load |
break |
设置断点 | (gdb) break main |
continue |
继续运行 | (gdb) continue |
step |
单步进入 | (gdb) step |
next |
单步跳过 | (gdb) next |
print |
打印变量值 | (gdb) print counter |
info registers |
查看寄存器 | (gdb) info registers |
backtrace |
查看调用栈 | (gdb) backtrace |
2.3.3 一个完整的调试流程
假设你要调试一个LED闪烁程序，怀疑延时函数有问题。流程如下：
- 启动OpenOCD：
openocd -f my_board.cfg - 启动GDB：
arm-none-eabi-gdb led_blink.elf - 连接目标：
(gdb) target remote localhost:3333 - 下载固件：
(gdb) load - 在延时函数设断点：
(gdb) break delay_ms - 运行：
(gdb) continue - 程序停在
delay_ms，用step单步进去看循环变量 - 用
print i查看循环计数
你想想看，IDE里点来点去，其实底层也是这么干的。GDB的好处是你可以写脚本自动化调试，比如每次断点都打印某个变量——这在排查复杂bug时特别有用。
2.4 知识结构总览
下面这张图把调试工具链的层次关系画清楚了。从调试器硬件到GDB命令行，每一层都有对应的配置和命令。
这张图把调试工具链的层次关系画得很清楚。从上到下，每一层都依赖下层正确配置。硬件没装好驱动，OpenOCD就认不出调试器；OpenOCD没配好目标芯片，GDB就连不上MCU。所以，搭建工具链时，从底层往上逐层验证，是最稳妥的做法。