Ubuntu下搭建OpenOCD与GDB ARM嵌入式调试环境：从原理到实战-尧图网络科技

1. 项目概述：为什么我们需要OpenOCD与arm-none-eabi-gdb这对组合？

如果你正在Ubuntu上捣鼓一块STM32、GD32或者任何基于ARM Cortex-M/R/A内核的开发板，并且厌倦了每次修改代码都要按一下下载按钮，看着进度条走完才能知道程序跑没跑对，那么你大概率已经走到了需要“在线调试”这一步。这不仅仅是把程序烧录进去，而是要让代码在你的眼皮子底下，一行一行地执行，随时可以查看变量、寄存器的状态，甚至像电影里演的那样，让时间暂停。在嵌入式开发的世界里，实现这个魔法的主要工具链就是GDB（GNU调试器）。但这里有个关键问题：你的开发环境（x86_64架构的Ubuntu）和你的目标芯片（ARM架构）指令集不同，你没法直接在Ubuntu上运行一个ARM程序并用本地的GDB去调试它。

这就是arm-none-eabi-gdb出场的原因。它是一个“交叉调试器”，本身运行在你的x86电脑上，但它理解ARM的机器指令，能够解析你编译出来的ARM格式的可执行文件（通常是.elf文件）。然而，光有能理解ARM的调试器还不够，调试器需要一种方式与那块实实在在的芯片“对话”，告诉它：“停！执行到下一行”，或者“把0x20000000地址开始的4个字节数据读给我”。这个负责与硬件芯片沟通的“翻译官”和“信使”，就是OpenOCD。

OpenOCD（Open On-Chip Debugger）是一个开源的在片调试器。它充当了GDB服务器（GDB Server）的角色。你的arm-none-eabi-gdb作为客户端（GDB Client），通过TCP/IP网络连接（通常是本地localhost:3333端口）向OpenOCD发送高级调试命令。OpenOCD则通过USB连接的JTAG/SWD调试器（比如ST-Link、J-Link、DAPLink等），将这些命令转换成芯片调试接口能识别的底层信号，从而控制芯片的核心、访问内存。所以，整个调试环境的搭建，核心就是让arm-none-eabi-gdb（客户端）和OpenOCD（服务器）在Ubuntu上就位，并正确连接。

最近在社区里，我看到不少朋友卡在类似“openocd: gdb server quit unexpectedly”或者“error: unable to start debugging. unexpected gdb output”这样的错误上，其根源往往就是这三者（GDB、OpenOCD、调试器驱动）的版本不匹配、配置不对，或者权限有问题。今天，我就以最常用的STM32平台和ST-Link调试器为例，带你从零开始，在Ubuntu 22.04 LTS上，完整搭建这套开源的ARM调试环境，并解决那些常见的坑。

2. 环境准备：安装编译工具链与OpenOCD

在邀请两位主角登场之前，我们需要先把舞台搭好。这个舞台就是ARM的交叉编译工具链。我们不仅需要调试器，还需要编译器来生成可供调试的、带调试信息的.elf文件。

2.1 安装ARM GNU工具链（包含arm-none-eabi-gdb）

最权威的来源是ARM官方或ARM开发者社区维护的版本。我们将把它添加到系统的APT源中，以便安装和后续更新。

首先，打开终端，添加工具链的仓库和密钥：

sudo apt-get update sudo apt-get install -y software-properties-common sudo add-apt-repository -y ppa:team-gcc-arm-embedded/ppa

注意：ppa:team-gcc-arm-embedded/ppa这个PPA在较新的Ubuntu版本（如24.04）可能已不再被维护。如果添加失败或安装时找不到包，我们可以采用更通用的方法：直接从ARM官网或第三方维护的仓库安装。这里以使用apt.armbian.com的仓库为例（它通常包含较新的版本且维护良好）：

# 移除可能失效的PPA（如果之前添加过） sudo add-apt-repository --remove -y ppa:team-gcc-arm-embedded/ppa # 添加Armbian的ARM工具链仓库（适用于Ubuntu/Debian） echo "deb [arch=amd64] http://apt.armbian.com $(lsb_release -sc) main utils" | sudo tee /etc/apt/sources.list.d/armbian.list wget -O- https://apt.armbian.com/armbian.key | sudo apt-key add - sudo apt-get update

现在，安装完整的ARM嵌入式工具链，它包含了编译器（gcc）、调试器（gdb）、二进制工具（binutils）等：

sudo apt-get install -y gcc-arm-none-eabi gdb-arm-none-eabi

安装完成后，验证一下关键工具：

arm-none-eabi-gcc --version arm-none-eabi-gdb --version

你应该能看到GCC和GDB的版本号。记下GDB的版本（比如12.1），这在后面与OpenOCD配合时很重要。

2.2 安装OpenOCD

Ubuntu的官方仓库里通常有OpenOCD，但版本可能较旧。对于支持最新的芯片，建议安装更新版本的OpenOCD。我们可以从官方源码编译，或者使用其他维护良好的PPA。

方法一：使用官方APT仓库（可能版本较旧但最稳定）

sudo apt-get install -y openocd

方法二：使用OpenOCD官方推荐的Nightly PPA（版本较新）

sudo add-apt-repository -y ppa:openocd-dev/ppa sudo apt-get update sudo apt-get install -y openocd

安装后，验证OpenOCD版本及其对ST-Link的支持：

openocd --version openocd -c "adapter driver" 2>&1 | grep stlink

如果看到stlink相关的输出，说明OpenOCD包含了ST-Link的驱动。

我个人更倾向于方法二，因为新版本修复了更多硬件兼容性和Bug。例如，社区高频搜索的“gdb server quit unexpectedly”错误，在某些旧版本中是一个已知问题，在新版本中可能已被修复。

2.3 配置USB调试器权限（解决“找不到ST-Link”问题）

这是第一个实战坑点。在Linux下，直接连接ST-Link等USB调试器，需要root权限才能访问。每次调试都用sudo很不方便，也不安全。正确的做法是将当前用户加入到对应的plugdev组，并设置持久的udev规则。

将用户加入plugdev组（如果尚未加入）：
```
sudo usermod -a -G plugdev $USER
```
需要注销并重新登录，或者开启新的终端会话，这个组变更才会生效。

创建ST-Link的udev规则文件：

echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="0666", GROUP="plugdev"' | sudo tee /etc/udev/rules.d/70-st-link.rules echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="374b", MODE="0666", GROUP="plugdev"' | sudo tee -a /etc/udev/rules.d/70-st-link.rules echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3752", MODE="0666", GROUP="plugdev"' | sudo tee -a /etc/udev/rules.d/70-st-link.rules

这里0483是ST公司的USB Vendor ID。3748、374b、3752分别对应ST-Link/V2、ST-Link/V2-1、ST-Link/V3的Product ID。这条规则让plugdev组内的用户对这些USB设备拥有读写权限。

重新加载udev规则并触发：

sudo udevadm control --reload-rules sudo udevadm trigger

拔掉并重新插入ST-Link。现在，你应该可以在普通用户权限下，通过lsusb命令看到ST-Link设备了：
```
lsusb | grep 0483
```

3. 实战第一步：编写一个简单的测试固件

调试环境需要调试对象。我们创建一个最简单的STM32程序，它不依赖复杂的HAL库，仅通过直接操作寄存器让一个LED闪烁，这样编译出的.elf文件很小，且调试信息清晰。

假设你的工程目录为~/stm32_debug_test。

创建工程目录和源文件：

mkdir -p ~/stm32_debug_test cd ~/stm32_debug_test

编写主程序main.c（以STM32F103C8T6，LED接在PC13为例）：

#include <stdint.h> // 简单延时函数 void delay(uint32_t count) { for (volatile uint32_t i = 0; i < count; ++i) { __asm__("nop"); } } int main(void) { // 1. 使能GPIOC时钟 (APB2ENR bit 4) volatile uint32_t *rcc_apb2enr = (volatile uint32_t*)0x40021018; *rcc_apb2enr |= (1 << 4); // 2. 配置PC13为推挽输出，最大速度2MHz (CRH寄存器) volatile uint32_t *gpioc_crh = (volatile uint32_t*)0x40011004; *gpioc_crh = (*gpioc_crh & 0xFF0FFFFF) | 0x00200000; // CNF=00, MODE=01 // 3. 主循环：翻转PC13 volatile uint32_t *gpioc_odr = (volatile uint32_t*)0x4001100C; while (1) { *gpioc_odr ^= (1 << 13); // 翻转PC13 delay(500000); // 简单延时 } return 0; }

编写链接脚本linker.ld（简化版，定义内存布局）：

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K } SECTIONS { .text : { *(.vector_table) *(.text*) } > FLASH .data : { *(.data*) } > RAM AT > FLASH .bss : { *(.bss*) } > RAM _end = .; }

编写启动文件startup.s（简化向量表）：

.section .vector_table, "a" .global _reset_vector _reset_vector: .word _stack_top /* 初始栈指针 */ .word _reset_handler /* 复位向量 */ .section .text .global _reset_handler _reset_handler: bl main b .

编写MakefileMakefile：

TARGET = test MCU = cortex-m3 CC = arm-none-eabi-gcc OBJCOPY = arm-none-eabi-objcopy OBJDUMP = arm-none-eabi-objdump GDB = arm-none-eabi-gdb CFLAGS = -mcpu=$(MCU) -mthumb -Og -g3 -std=c11 -Wall -Wextra LDFLAGS = -T linker.ld -nostartfiles -Wl,-Map=$(TARGET).map -specs=nano.specs OBJS = startup.o main.o all: $(TARGET).elf $(TARGET).bin $(TARGET).hex $(TARGET).elf: $(OBJS) $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ %.o: %.c $(CC) $(CFLAGS) -c $< -o $@ %.o: %.s $(CC) $(CFLAGS) -c $< -o $@ %.bin: %.elf $(OBJCOPY) -O binary $< $@ %.hex: %.elf $(OBJCOPY) -O ihex $< $@ flash: $(TARGET).elf openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "program $< verify reset exit" debug: $(TARGET).elf $(GDB) -ex "target extended-remote localhost:3333" $< clean: rm -f *.o *.elf *.bin *.hex *.map .PHONY: all flash debug clean

在终端中执行make，你应该能在目录下看到生成的test.elf、test.bin等文件。这个test.elf就是我们后续调试的核心文件，它包含了所有的符号和调试信息。

4. 启动OpenOCD GDB服务器并与硬件连接

现在，硬件、软件、固件都已就绪，让我们启动调试服务器。

4.1 连接硬件并启动OpenOCD

将你的ST-Link调试器通过USB连接到电脑。
用杜邦线将ST-Link的SWDIO、SWCLK、GND、3.3V（或VCC）与STM32开发板对应引脚连接好。确保板子已供电。
在终端中，进入你的工程目录，运行以下命令启动OpenOCD：
```
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg
```
- -f interface/stlink.cfg：指定使用ST-Link调试器接口。
- -f target/stm32f1x.cfg：指定目标芯片为STM32F1系列。如果你的芯片是F4，则应为stm32f4x.cfg。OpenOCD在/usr/share/openocd/scripts/（或类似路径）下提供了大量预定义的配置文件。

如果一切正常，OpenOCD会输出类似以下的信息，并停留在等待状态：

Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : Listening on port 3333 for gdb connections

重点：3333端口就是留给GDB连接的。4444是Telnet端口，可以用来执行一些OpenOCD命令（如内存读写、复位）。这个终端窗口需要保持运行，不要关闭。

4.2 常见启动问题排查

如果OpenOCD启动失败，以下是几个排查方向：

错误:Error: open failed或Error: unable to open stlink device：
- 权限问题：这是最常见的原因。请务必确认你已经完成了第2.3节的udev规则配置，并且重新插拔了ST-Link，同时当前用户已在新会话中（重新登录或新开终端）。
- 设备被占用：是否有其他程序（如IDE、另一个OpenOCD实例）占用了ST-Link？用ps aux | grep openocd检查并结束进程。
- 驱动问题：在极少数情况下，可能需要卸载stlink-tools（如果安装了）以避免冲突：sudo apt remove stlink-tools。
错误:Error: unable to find target/stm32f1x.cfg：
- OpenOCD的脚本路径可能不在默认搜索路径。使用s选项指定脚本路径：
```
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg
```
- 或者，直接使用配置文件的绝对路径。
错误:Warn : UNEXPECTED idcode：
- 芯片IDCODE读取错误。检查硬件连接（SWDIO, SWCLK）是否牢固，电源是否正常。尝试降低JTAG/SWD速度，在interface/stlink.cfg同级目录创建一个自定义配置文件（如my_custom.cfg），内容为adapter speed 100，然后启动时加载它：openocd -f interface/stlink.cfg -f my_custom.cfg -f target/stm32f1x.cfg。

5. 使用arm-none-eabi-gdb进行命令行调试

保持OpenOCD在第一个终端运行，现在打开第二个终端，进入工程目录，开始我们的GDB调试之旅。

5.1 启动GDB并连接

arm-none-eabi-gdb test.elf

这会启动GDB，并加载我们的调试符号。在GDB提示符(gdb)下，输入：

target extended-remote localhost:3333

如果连接成功，你会看到类似Remote debugging using localhost:3333的提示。这条命令告诉GDB去连接本地3333端口上的OpenOCD服务器。

5.2 基础调试操作

现在，你可以像调试本地程序一样调试这个远程的ARM芯片了。

加载程序到芯片Flash：
```
load
```
这个命令会将test.elf文件中的代码段和数据段烧录到芯片的Flash中。OpenOCD会自动处理擦除、编程、校验。你会在OpenOCD的终端看到编程进度。
运行与停止：
```
continue # 或简写为 c， 让程序开始运行
```
程序开始运行，LED应该开始闪烁。要中断程序执行，回到GDB控制，在GDB终端按Ctrl+C。

设置断点与单步执行：

break main # 在main函数入口设置断点，简写为 b main run # 重新运行程序，会停在main函数的第一行。简写为 r next # 单步执行（不进入函数），简写为 n step # 单步执行（进入函数），简写为 s finish # 执行完当前函数，返回到调用处

查看与修改：

print *rcc_apb2enr # 查看RCC_APB2ENR寄存器的值 x/4x 0x4001100C # 以十六进制查看GPIOC_ODR地址开始的4个字 set variable (*gpioc_odr) = 0x00000000 # 将PC13输出置低（假设ODR寄存器可位操作，此处仅为示例语法） info registers # 查看所有核心寄存器（R0-R15, xPSR等）

监控变量与内存：

watch *gpioc_odr # 硬件监视点，当GPIOC_ODR的值改变时中断（需要芯片支持） x/20b &delay_counter # 以字节形式查看delay_counter变量地址开始的20个字节

5.3 一个完整的调试会话示例

让我们模拟一次完整的调试过程，检查main.c中时钟使能是否成功。

# 在GDB中操作 (gdb) target extended-remote localhost:3333 (gdb) load (gdb) break main (gdb) continue # 程序停在main函数开头 (gdb) next # 执行完 `*rcc_apb2enr |= (1 << 4);` (gdb) print/x *rcc_apb2enr # 输出应为类似 0x00000010，表示第4位被置1，GPIOC时钟已开启。 (gdb) next # 执行配置GPIOC为输出 (gdb) print/x *gpioc_crh # 查看配置结果 (gdb) continue # 让程序自由运行，LED闪烁 # 按 Ctrl+C 中断 (gdb) backtrace # 查看调用栈，确认中断位置 (gdb) kill # 终止当前调试会话（程序停止） (gdb) run # 重新开始

6. 高级配置与图形化前端集成

命令行GDB功能强大，但有时我们更需要直观的图形界面。这里介绍两种主流方式：使用GDB的文本用户界面（TUI）和集成到VSCode。

6.1 使用GDB自带的TUI模式

TUI（Text User Interface）模式可以在终端内分屏显示源代码、汇编和寄存器，非常方便。启动GDB时加上-tui参数，或者在GDB内按Ctrl+X+A切换：

arm-none-eabi-gdb -tui test.elf

连接、设置断点后，你会看到屏幕上半部分显示源代码，下半部分是GDB命令窗口。使用方向键可以滚动源代码。这对于理解程序流程和查看上下文代码非常有用。

6.2 配置VSCode进行图形化调试（推荐）

VSCode通过Cortex-Debug插件提供了极佳的嵌入式调试体验。

安装插件：在VSCode扩展商店搜索并安装Cortex-Debug。

创建调试配置：在工程根目录创建.vscode/launch.json文件：

{ "version": "0.2.0", "configurations": [ { "name": "Cortex Debug (OpenOCD)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/test.elf", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "serverpath": "/usr/bin/openocd", // 确认你的openocd路径 "serverArgs": [ "-f", "interface/stlink.cfg", "-f", "target/stm32f1x.cfg" ], "device": "STM32F103C8", "interface": "swd", "runToEntryPoint": "main", "svdFile": "${workspaceRoot}/STM32F103xx.svd" // 可选，用于外设寄存器视图 } ] }

开始调试：按F5或点击调试按钮。VSCode会自动启动OpenOCD，连接GDB，加载程序，并停在main函数。你可以使用图形化按钮进行单步、继续、查看变量/调用栈/外设寄存器（如果提供了SVD文件）等操作，体验远超命令行。

实操心得：Cortex-Debug插件的一个巨大优势是它能解析SVD（System View Description）文件，以图形化方式展示芯片所有外设寄存器的位域，这对于调试底层驱动至关重要。ST官网通常提供芯片的SVD文件。

7. 深度排错：解决“Unexpected GDB Output”与服务器意外退出

现在，我们来直面那些令人头疼的错误信息。根据网络热词，openocd: gdb server quit unexpectedly和error: unable to start debugging. unexpected gdb output from command "-exec-是高频问题。

7.1 问题根因分析

这类错误通常不是单一原因，而是GDB客户端与OpenOCD服务器之间通信协议不匹配或理解不一致导致的。可能的原因包括：

版本不兼容：较新版本的GDB可能使用了旧版OpenOCD不支持的调试协议扩展，或者反之。这是最常见的原因。
连接不稳定：USB线缆质量差、接触不良，或者系统电源管理导致USB口休眠。
目标芯片状态异常：芯片处于低功耗模式、被写保护、或者之前调试会话异常终止导致调试逻辑锁死。
配置文件错误：OpenOCD的配置文件指定了不支持的芯片或接口参数。
多进程冲突：多个GDB实例试图连接同一个OpenOCD，或者OpenOCD进程本身异常。

7.2 系统性排查流程

当遇到GDB连接失败或服务器退出的问题时，请按以下步骤排查：

第一步：检查OpenOCD服务器日志仔细阅读启动OpenOCD的那个终端里的所有输出，特别是错误（Error）和警告（Warn）信息。这些是定位硬件连接和配置问题的第一手资料。

第二步：验证GDB与OpenOCD的基础连接在GDB中执行最简单的命令，测试连接是否真的建立：

(gdb) target extended-remote localhost:3333 (gdb) monitor reset halt # 通过OpenOCD发送复位并暂停命令

如果monitor命令无响应或报错，说明连接层面就有问题。monitor命令是GDB发送给OpenOCD的特有命令。

第三步：降低通信速度与启用详细日志在OpenOCD启动配置中增加调试信息并降低适配器速度：

openocd -f interface/stlink.cfg -c "adapter speed 100" -f target/stm32f1x.cfg -d3

-d3参数会输出大量调试信息，有助于看清通信细节。adapter speed 100将SWD/JTAG速度降至100kHz，排除因速度过高导致的时序问题。

第四步：尝试不同的GDB/OpenOCD版本组合如果你使用的是非常新的GDB（如12.x, 13.x）和较旧的OpenOCD（如0.10.x），尝试降级GDB或升级OpenOCD。一个经过验证的稳定组合是：GDB 10.x 或 11.x 搭配 OpenOCD 0.12.x。你可以通过apt安装特定版本，或从源码编译。

第五步：对芯片进行完全复位有时芯片的调试单元会卡住。尝试在OpenOCD连接后，通过Telnet接口发送强制复位命令：

新开一个终端，连接OpenOCD的Telnet端口：telnet localhost 4444

在Telnet会话中依次输入：

reset halt stm32f1x unlock 0 # 如果是STM32F1，尝试解除读写保护（谨慎使用，会擦除Flash） reset halt

然后回到GDB重试连接。

第六步：精简调试环境关闭所有可能占用ST-Link或OpenOCD端口的程序（包括IDE、其他终端里的OpenOCD）。使用netstat -tulpn | grep 3333检查端口占用情况。

7.3 针对“-exec-”错误的专项处理

unexpected gdb output from command "-exec-这个错误，经常发生在VSCode的Cortex-Debug插件环境中。这通常是插件发送的某个GDB命令（如-exec-run）没有得到它期望的响应。

解决方案A：更新所有组件。确保VSCode、Cortex-Debug插件、OpenOCD、GDB都更新到最新版本。

解决方案B：修改VSCode调试配置。在launch.json中，为cortex-debug配置增加以下参数，禁用一些可能引发问题的特性：

"configurations": [{ ... "overrideLaunchCommands": [ "monitor reset halt", "load" ], "overrideRestartCommands": [ "monitor reset halt" ], "showDevDebugOutput": "raw", // 显示原始GDB通信，用于诊断 "request": "attach", // 有时将"launch"改为"attach"模式能绕过初始化问题 "runToMain": false // 先不运行到main }]

解决方案C：回退GDB版本。这是最有效的“笨办法”。从ARM官网下载一个稍旧版本（如10.3-2021.10）的预编译工具链，解压后，在VSCode配置或Makefile中指定使用这个特定路径的GDB。

8. 性能调优与生产环境建议

当调试环境稳定后，我们还可以做一些优化，使其更高效、更适应团队协作或自动化脚本。

8.1 OpenOCD配置优化

你可以将常用的OpenOCD命令写在一个自定义的配置文件中，例如debug.cfg：

# debug.cfg source [find interface/stlink.cfg] adapter speed 5000 # 根据你的板和线缆质量适当提高速度，如5000 kHz transport select swd source [find target/stm32f1x.cfg] # 初始化脚本：连接后自动执行 $_TARGETNAME configure -event gdb-attach { echo "GDB connected, resetting target..." reset halt } $_TARGETNAME configure -event gdb-detach { echo "GDB detached." }

然后只需用openocd -f debug.cfg启动即可。

8.2 GDB初始化脚本自动化

在工程根目录创建.gdbinit文件，GDB启动时会自动执行其中的命令，实现自动化连接和初始化：

# .gdbinit set confirm off set mem inaccessible-by-default off target extended-remote localhost:3333 monitor reset halt load break main continue

这样，每次你运行arm-none-eabi-gdb test.elf，它会自动连接服务器、复位芯片、加载程序、在main处设断点并开始运行。

8.3 将调试集成到Makefile

如前文Makefile示例所示，定义make debug目标可以一键启动GDB并连接。你可以进一步扩展，使其能自动启动OpenOCD：

.PHONY: debug-server debug-server: @echo "Starting OpenOCD..." @openocd -f interface/stlink.cfg -f target/stm32f1x.cfg > /dev/null 2>&1 & @sleep 2 # 等待OpenOCD启动 .PHONY: debug-attach debug-attach: debug-server $(GDB) -ex "target extended-remote localhost:3333" -ex "monitor reset halt" -ex "load" $(TARGET).elf .PHONY: kill-server kill-server: @pkill -f "openocd" || true

使用make debug-attach可以一键完成整个流程。make kill-server用于清理。

8.4 关于“Connect Under Reset”的使用

在一些特殊情况下（如芯片处于低功耗模式、选项字节配置错误导致SWD引脚被禁用），需要使用“Connect Under Reset”功能。这需要在硬件上控制芯片的NRST引脚，并在OpenOCD配置中启用。对于ST-Link，你需要将ST-Link的NRST引脚与芯片的NRST引脚连接。然后在OpenOCD配置中增加：

# 在interface/stlink.cfg 或自定义配置中 reset_config srst_only srst_nogate connect_assert_srst

srst_only表示只使用硬件复位线，connect_assert_srst表示在连接时保持复位状态，这可以确保调试器在芯片完全复位的情况下建立连接，从而访问被禁用的SWD接口。

搭建起OpenOCD + arm-none-eabi-gdb这套开源调试环境，就像是给你的嵌入式开发装备上了一套高精度内窥镜和手术刀。初期可能会在环境配置和版本兼容性上花费一些时间，但一旦打通，它所提供的底层控制能力和调试自由度，是许多集成IDE无法比拟的。这套组合不仅适用于STM32，通过更换OpenOCD的target配置文件，它可以支持几乎所有带JTAG/SWD接口的ARM芯片，甚至是RISC-V等其他架构，其价值会随着你项目的深入而不断放大。