必须手动切换J-Link驱动为OpenOCD兼容版（如“J-Link (BULK Interface)”），否则因Segger原厂驱动不支持libusb BULK接口导致LIBUSB_ERROR_ACCESS；serverpath需指向openocd可执行文件，configFiles中interface配置必须在target之前且适配SWD模式，编译须含-g3 -Og并保留.debug_*节。
能用，但必须手动切换J-Link驱动模式，否则OpenOCD根本连不上芯片——这是最常卡住的一步，不是配置写错，而是硬件握手失败。
为什么openocd -f interface/jlink.cfg -f target/stm32f4x.cfg总报libusb_open() failed with LIBUSB_ERROR_ACCESS
这不是权限问题，也不是USB线坏了，而是J-Link当前在用Segger原厂驱动，而OpenOCD只能通过libusb的BULK接口通信。Windows设备管理器里看到的“J-Link”设备名没变，但底层驱动必须换成OpenOCD兼容版。
- 断开J-Link，打开设备管理器 → “通用串行总线设备”或“J-Link”条目 → 右键“更新驱动程序” → “浏览我的电脑以查找驱动程序” → “从磁盘安装”
- 下载
jlink_openocd_driver.inf（Segger官网提供，搜索“J-Link OpenOCD driver”即可找到） - 选中该INF文件后，系统会列出“SEGGER J-Link (Interface)”或类似名称，选它安装
- 重插J-Link，设备管理器中应显示为“J-Link (BULK Interface)”，此时
openocd -d2才能看到Info : J-Link V11.00 compiled ...日志
cortex-debug插件里serverpath和configFiles怎么填才不踩坑
路径错一个斜杠、少一个-f、顺序颠倒，都会导致OpenOCD启动失败且错误信息极不友好。关键不是语法对，而是OpenOCD实际加载的配置链必须匹配目标芯片物理连接方式。
-
serverpath必须指向openocd.exe（Windows）或openocd（Linux/macOS），不是目录；验证方式：终端直接运行该路径命令，看是否输出版本号 -
configFiles数组里，interface/类必须放在target/类前面，OpenOCD按顺序解析，先初始化调试器再找芯片 - STM32F4系列若只引出SWD（常见于小板子），不能直接用
jlink.cfg，要新建jlink_swd.cfg，内容只需两行：interface jlink+transport select swd，然后在configFiles里引用它 - Linux下路径用正斜杠
/，Windows下可用正斜杠或双反斜杠\，但千万别混用单反斜杠——JSON解析会把它当转义符吃掉
调试时Breakpoint ignored或No symbol table loaded怎么办
这通常不是GDB没连上，而是ELF文件本身缺失调试信息，或者Cortex-Debug没正确读取符号路径。OpenOCD和GDB都正常，但VSCode界面里变量全灰、断点空心，问题出在构建环节。
立即学习“C语言免费学习笔记（深入）”；
- 编译命令必须带
-g3 -Og（不是-O2），-g3生成完整调试符号，-Og保证优化不破坏行号映射 - 链接脚本里不能丢掉
.debug_*节区，检查arm-none-eabi-readelf -S firmware.elf | grep debug，至少要有.debug_info和.debug_line -
cortex-debug配置里的executable字段必须是绝对路径或相对于.vscode/的相对路径，且文件存在；建议用${workspaceFolder}/build/firmware.elf而非./build/firmware.elf - 如果用了CMake，确保
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g3 -Og")写在project()之后，否则可能被覆盖
真正麻烦的从来不是写配置，而是驱动层和物理层的隐式耦合——J-Link固件版本、OpenOCD配置文件里的transport选择、芯片复位电路设计，三者稍有不匹配，调试器就静默失败，连错误码都不报。动手前先用openocd -d2看初始化日志里有没有Info : SWD DPIDR 0x...这一行，有，说明物理握手成功；没有，别急着调VSCode，先查驱动和接线。
