上周帮同事看一块跑不起来的 F103 板子他打开 Keil 单步走了半天变量值全是optimized out串口也只有零星几行日志。我让他把工程挪到 VS Code接上 Cortex-Debug 和 OpenOCD十分钟之内定位到是一个中断里改错了控制寄存器。这件事之后我就更确定一件事嵌入式软件的调试能力跟编译器、跟 IDE 是绑死的而 VS Code 这条链路在看得见这件事上优势比很多人想象的大得多。这篇就聊透用 VS Code 调试 STM32 程序这件事——从工程改造、launch.json 配置、连不上板子怎么查、HardFault 现场怎么还原一直到把这套流程和 AI 编程工具接起来。适合已经能让 STM32 跑起来、但调试手段还停留在加 printf 大法的朋友也适合从 Keil、IAR 迁过来踩过坑的人。1. 我为什么把 STM32 的调试主战场搬到了 VS Code1.1 Keil 的调试舒适区以及它开始不够用的那条线先把话说清楚Keil 的调试器并不差。芯片包安装一路下一步Peripherals 窗口点开就能看寄存器结构体变量在 Watch 里能一层层展开Debug 模式下的逻辑分析仪对 GPIO 翻转做时序观察也很方便。如果只是一个人做一块小板子量级在几千行代码Keil 完全够用。真正卡住我的是几个具体场景。第一个是协作Keil 的工程文件是二进制加 XML 混合的.uvprojx多人同时改配置合并冲突基本没法解最后只能约定谁改配置谁说话。第二个是脚本化我想在 CI 上跑一遍编译或者想写个脚本自动烧录加复位Keil 的命令行模式能做的事很有限。第三个也是这两年最要命的——AI 编程工具几乎都长在 VS Code 里。我想要补全、想要 AI 帮我读一份 OpenOCD 的报错日志、想让它照着参考手册生成寄存器位定义这些事在 Keil 里做起来很别扭。还有个小细节很多人踩过Keil 的 Debug 模式下看结构体变量得先确定符号表加载对了一旦开了较高级别优化Watch 窗口里就会出现cannot evaluate或者直接不显示。这不是 Keil 的错是优化把变量折叠掉了但在 VS Code 这边因为整个工具链是 GCC 的编译参数全在你手里反而更容易把这个问题治明白。1.2 VS Code 调 STM32 的完整链路其实是四段拼起来的很多人第一次配会晕本质是没搞清这条链路上有四个独立角色角色具体是什么负责什么编辑器/前端VS Code显示界面、断点、变量窗口调试适配器Cortex-Debug 扩展把 VS Code 的调试请求翻译成 GDB 命令调试器arm-none-eabi-gdb真正理解符号表、栈帧、表达式的那个探针服务OpenOCD / pyOCD / ST-Link GDB Server通过 USB 跟 ST-Link、J-Link、DAPLink 说话再转成 SWD 时序VS Code 本身不会调试任何东西Cortex-Debug 也不懂 SWD 时序。你点一下下一步是 VS Code 通知 Cortex-DebugCortex-Debug 让 GDB 发stepGDB 让 OpenOCD 控制探针拉一次 SWCLK。任何一环断了表现都是连不上或者断点打不上但原因完全不同。把这张图记住后面排查会省很多时间。1.3 迁移的代价我提前告诉你别以为这是零成本的升级。你要付出的代价大概是这些第一次配 launch.json 要花半天到一天OpenOCD 的报错信息默认相当不友好得学会看它的日志便宜的 ST-Link V2 山寨探针在 SWO 引脚上支持很差如果你想要 ITM 打印可能得换 ST-Link V3 或者 J-Link。另外用 GDB 看外设寄存器需要 SVD 文件芯片原厂的器件包里不一定好找得去 CMSIS-SVD 的开源库里翻。但一次性投入换回来的是所有配置都是文本能进 Git调试脚本能自动化AI 工具能直接读你的配置文件。这笔账我认为划算。2. 工程本身得先可被调试构建链路要干净2.1 用 CubeMX 生成 Makefile 工程别手搓链接脚本我的建议很直接用 STM32CubeMX 或者 CubeCLI 生成 Makefile 工程勾上生成外设初始化代码然后在此基础上写业务逻辑。为什么不手搓因为启动文件、链接脚本、向量表偏移这些地方手写错的概率很高而调试期的很多诡异现象比如断点打不上、跳转到 HardFault根源都在这。生成完之后目录长这样MyProject/ ├── Core/ │ ├── Inc/ │ └── Src/ ├── Drivers/ │ ├── CMSIS/ │ └── STM32F1xx_HAL_Driver/ ├── Makefile ├── STM32F103C8Tx_FLASH.ld └── MyProject.ioc.ld就是链接脚本向量表起始地址、RAM 和 FLASH 的分段都在里面。如果你用 bootloader 加 App 的双区方案VECT_TAB_OFFSET和链接脚本的FLASH ORIGIN都要跟着改两边不一致调试器就会把断点打在错误的地址上表现是程序能跑但断点位置对不上。用 CMake 也可以好处是 IDE 集成度更高CMAKE_EXPORT_COMPILE_COMMANDSON一行就能生成编译数据库IntelliSense 配置省事。代价是 CMake 那一层多了一次出错的机会新手我不太推荐。2.2 编译参数调试期的生死线这是我最想强调的一节。Keil 时代大家习惯在 Debug 配置里选 Level 0到了 GCC对应的参数不只是一个-O0。# 调试期推荐 OPT -Og DEBUG -g3 -gdwarf-4 CFLAGS $(DEBUG) $(OPT) \ -fno-omit-frame-pointer \ -fno-inline-small-functions \ -Wall逐个解释为什么。-Og是 GCC 专门为调试优化的级别。它在不显著破坏可调试性的前提下做了一些基本优化生成的代码体积比-O0小不少跑起来也更接近真实速度。纯-O0的问题是代码量可能直接顶爆小容量芯片的 Flash而且执行时序跟量产版本差太远你调出来的时序在 Release 下完全不一样。如果某个函数特别在意时序可以对单个文件加-O2这比全局切-O2稳妥得多。-g3比-g多带宏定义信息。你调试时想在 Watch 里输入一个宏名看展开结果没有-g3是看不到的。-gdwarf-4是格式版本这里有个真实的坑-g默认在新一点的 GCC 上会生成 DWARF 5而某些旧版本的 GDB尤其是芯片厂商随 IDE 附带的那个不认 DWARF 5症状是符号加载成功但变量全是问号。我遇到过好几次最后发现就是版本不匹配。加个-gdwarf-4立刻好。-fno-omit-frame-pointer是为了让 GDB 在解析调用栈时更省事。Cortex-M 上其实有更可靠的办法后面讲 HardFault 时会说但保留帧指针能让bt命令的结果更可信。还有一个常见问题-flto链接时优化。调试期千万别开。它会把函数合并、内联得面目全非断点位置和源码完全对不上符号名也可能变成foo.lto.0这种。2.3 compile_commands.json 与符号对齐VS Code 的 C/C 扩展靠compile_commands.json或c_cpp_properties.json来知道头文件路径和宏定义。调试器则靠 ELF 文件里的 DWARF 段。这两个东西的来源要一致否则会出现代码里跳转正常但调试时定位到另一行的诡异情况。生成compile_commands.json有几种路子用bear -- make或者compiledb make包一层或者 CMake 工程直接开CMAKE_EXPORT_COMPILE_COMMANDS再或者 CubeMX 部分版本支持直接生成。我通常用 bear简单粗暴sudo apt install bear bear -- make -j8然后.vscode/c_cpp_properties.json里指向它{ configurations: [ { name: STM32, compileCommands: ${workspaceFolder}/compile_commands.json, defines: [USE_HAL_DRIVER, STM32F103xB], cStandard: c11, intelliSenseMode: gcc-arm } ], version: 4 }defines里那两个宏特别重要HAL 库的头文件里到处是条件编译缺了它 IntelliSense 会一片红代码补全也没法用。至于 VS Code 本身的安装和中文界面这类基础问题官网下载对应平台安装包装完在扩展面板搜 Chinese 装语言包就行这里不展开。3. launch.json 里每一行到底在干什么3.1 一份可以直接抄的最小配置先给一份能跑的再逐行拆。{ version: 0.2.0, configurations: [ { name: Debug (OpenOCD), type: cortex-debug, request: launch, cwd: ${workspaceFolder}, executable: ${workspaceFolder}/build/MyProject.elf, servertype: openocd, configFiles: [ interface/stlink.cfg, target/stm32f1x.cfg ], device: STM32F103C8, interface: swd, svdFile: ${workspaceFolder}/svd/STM32F103xx.svd, runToEntryPoint: main, armToolchainPath: /usr/bin, gdbPath: /usr/bin/arm-none-eabi-gdb, preLaunchTask: build, showDevDebugOutput: none, breakAfterReset: true } ] }3.2 servertype 怎么选各有什么脾气servertype适用探针优点需要注意openocdST-Link、DAPLink、CMSIS-DAP 通吃配置灵活能写脚本跨平台配置文件路径要写对报错信息晦涩stlink-gdb-server官方 ST-Link含 V3开箱即用SWO 支持好老版本工具不支持部分芯片pyocdDAPLink、ST-Link 也支持Python 生态能写脚本控制芯片支持包要单独装jlinkJ-Link速度快支持芯片多需要装 SEGGER 的软件包协议允许范围内使用我日常用 OpenOCD 最多原因是它配置文件就是文本能进版本库团队里谁都能看懂。interface/stlink.cfg是新版 OpenOCD 的写法老版本里叫interface/stlink-v2.cfg如果你复制网上的配置报file not found先看看你本地scripts/interface/目录下实际叫什么名字。3.3 几个容易被忽略但很关键的字段executable指的那个 ELF 文件必须是当前这次编译产物。我踩过的最蠢的坑就是改了代码忘了重新编译调试器加载的是旧符号表断了半天发现变量值永远是上一次的。所以preLaunchTask一定要配上让它在启动调试前自动跑编译任务。runToEntryPoint设为main意思是复位后先停在 main 入口而不是第一条指令。对只想调业务逻辑的人很省事。但如果你要排查启动流程、时钟初始化这些早期问题就得把它去掉手动从Reset_Handler开始单步。svdFile是外设寄存器可视化的关键。有了它调试侧边栏会多出一个 XPERIPHERALS 区域你可以像看 Excel 一样看 GPIOA 的 ODR 哪一位是 1、TIM2 的 CNT 现在是多少。这个文件从芯片厂商的器件包或者开源的 cmsis-svd 仓库里找注意型号要对应F103C8 和 F103RC 的外设列表不完全一样。breakAfterReset建议开着。否则 OpenOCD 复位之后立刻放行你根本来不及看启动瞬间的状态。3.4 再加一个 attach 配置热接上正在跑的程序有时候板子已经跑着你不想重新烧只想连上去看看当前状态。这时候request改成attach{ name: Attach (不烧录), type: cortex-debug, request: attach, servertype: openocd, executable: ${workspaceFolder}/build/MyProject.elf, configFiles: [interface/stlink.cfg, target/stm32f1x.cfg], interface: swd, svdFile: ${workspaceFolder}/svd/STM32F103xx.svd }Attach 模式下断点能不能打取决于目标代码的符号表是否和当前运行的程序一致以及你用的是硬件断点还是软件断点。硬件断点一定能打软件断点需要调试器往 Flash 或 RAM 里写指令Flash 里写不进去就会失败——这个后面细说。4. 连不上目标板我按这个顺序往下查Failed to launch GDB 这个弹窗是新手最容易被劝退的地方因为它什么信息都不给。我的排查顺序是固定的从最外层往里剥。4.1 第一步永远是确认探针被系统认出来了这一步在 Windows 上看设备管理器在 Linux 上跑lsusblsusb | grep -i st-link # 期望输出类似 # Bus 001 Device 012: ID 0483:3748 STMicroelectronics ST-LINK/V2如果什么都看不到别往下查了是 USB 线、接口或者驱动的问题。注意有大量廉价线材只有供电线没有数据线我至少被这个坑过三次。Linux 下还有一层 udev 权限问题普通用户访问不到 USB 设备需要加规则sudo tee /etc/udev/rules.d/49-stlinkv2.rules EOF SUBSYSTEMSusb, ATTRS{idVendor}0483, ATTRS{idProduct}3748, MODE0666 EOF sudo udevadm control --reload-rules sudo udevadm trigger这个是 ST-Link 官方的 udev 规则写法其他厂商的探针改 VID/PID 即可。4.2 SWD 接线和引脚复用一半的连不上在这SWD 只需要四根线SWDIO、SWCLK、GND、以及可选的 NRST。3.3V 要不要接取决于你的板子是否已经独立供电两块电源同时供容易出问题。芯片侧STM32F1 上默认是 PA13SWDIO和 PA14SWCLK。常见坑有几个代码里把 PA13、PA14 配成了普通 GPIO 或者复用作别的功能一上电就把调试口关了。这时候必须用复位下连接connect under reset才能救回来。PB3、PB4 是 JTAG 的引脚虽然 SWD 用不到但如果你在 CubeMX 里没把 JTAG 关掉__HAL_AFIO_REMAP_SWJ_NOJTAG()这几根脚也没法当普通 IO 用。线太长、杜邦线接触不良。SWD 时钟在 1MHz 以上时对线材敏感可以先在 OpenOCD 里把adapter speed降到 500 甚至 100 试试能连上再往上调。Connect under reset 在 OpenOCD 里的写法是在配置文件里加reset_config srst_only srst_nogate connect_assert_srst或者在 launch.json 的configFiles后面追加一段openOCDLaunchCommands。原理是让探针在芯片还处于复位状态时就抢占总线避免固件跑起来把调试口改掉。4.3 被读保护锁死之后的恢复如果你烧过一个开了读保护RDP的固件或者误改了选项字节会看到target not halted或者干脆识别不到内核 ID。恢复的办法是擦除整片代价是 Flash 里的东西全没了openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \ -c init; reset halt; stm32f1x unlock 0; reset; shutdownstm32f1x unlock 0会把读保护等级退回 0这个过程会触发全片擦除是设计如此不是 bug。注意这个命令只对 F1 系列有效其他系列命令名不一样F0/F3 是stm32f0x unlock之类用之前查一下对应系列的手册。4.4 常见症状对因表症状大概率原因处理方向找不到 ST-Link线材/驱动/udev 权限先查系统层别动配置找不到目标电压目标板没供电或 3.3V 没接检查供电或接上 VTreftarget not halted固件关了 SWD 或进了低功耗connect under reset或拉低 BOOT0 从系统存储启动DAP 报错、握手失败时钟太快、线太长降 adapter speed 到 100kHz下载报 flash 写失败写保护、容量不对检查选项字节和链接脚本的 FLASH 长度断点打上但不触发优化导致地址错位、或旧 ELF重新编译调低优化等级这张表我基本是贴在工位上的省掉很多来回试。5. 断点、变量、寄存器真正干活时的观察手法5.1 硬件断点和软件断点的区别决定了你能打几个断点这个知识点很多人调到一半才发现然后一脸懵。Cortex-M 内核里有个叫 FPB 的单元提供硬件断点数量是固定的Cortex-M3/M4 通常 6 个指令断点加 2 个数据观察点M0/M0 只有 4 个。超出数量的断点GDB 会尝试用软件断点往目标地址写一条特殊指令比如 BKPT程序执行到那里触发异常。这招在 RAM 里跑的程序上没问题但在 Flash 上就不行了——Flash 不能随便写。所以如果你在 Flash 里的代码上打了第 7 个断点表现可能是断点图标变成灰色空心圈意思是设置失败。应对办法有几个。一是精简断点调完一段就删。二是在 RAM 里跑关键代码段用.ramfunc段这样软件断点能用。三是用条件断点代替多个断点比如在循环里只关心i 100那一次条件断点表达式i 100 命中次数跳过前 999 次VS Code 的断点右键菜单里可以填条件表达式和命中计数配合 Cortex-Debug 用起来很顺手比在循环里反复按继续快得多。5.2 变量观察从看不见到看得清先说很多人从 Keil 带过来的习惯在 Keil 的 Debug 模式里Watch 窗口能展开结构体看huart1.Instance-SR这种嵌套结构很直观。到了 VS Code对应的能力在变量面板和监视面板里操作逻辑差不多在WATCH区域点加号输入表达式。但有几个 GCC 特有的现象要习惯表达式可以带函数调用比如HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_5)GDB 会真的去执行这个函数。这在没有副作用的读函数上很方便但绝对不要在有副作用的函数上这么干。强制转换可用(uint32_t)some_ptr-field。数组越界读取buffer[100]即使超出长度也能读到内存内容这算调试特性方便你看栈溢出时被踩坏的区域。如果变量显示成optimized out说明编译器把它优化掉了。三个解法把-Og降到-O0把这个变量加volatile或者用__attribute__((used))强制保留。我一般优先选第一种调完再改回来。5.3 用 SVD 看外设寄存器比翻手册快十倍这是我认为 VS Code 相对 Keil 的一个隐藏优势点。配置好svdFile之后调试侧边栏的 XPERIPHERALS 区域会按外设分组列出所有寄存器每个位还能展开看位域。比如调串口通信不上直接看 USART1 的 SR 和 DR比在串口调试助手对面猜半天有用得多调 Modbus 从机不响应看一眼 USART 的 ORE 位是不是被置起来了立刻知道是不是波特率配错导致溢出。SVD 文件找法ST 的芯片包Keil 的 pack 或者 CubeMX 的安装目录里通常带着.svd找不到就去 GitHub 上搜cmsis-svd仓库那个仓库把各家厂商的 SVD 归了档。放工程目录下用相对路径引用方便整个团队共享。5.4 数据观察点抓谁改了我的变量这类问题最难查一个全局变量莫名其妙变了值代码里搜不到写它的地方——十有八九是数组越界踩内存或者中断里改了主循环的变量。硬件数据观察点就是干这个的。Cortex-M3/M4 有 2 个。在 GDB 里的写法# 监视某个地址的写操作长度 4 字节 watch *(uint32_t *)0x20000010 # 或按变量名 watch my_global_flag # 只看读操作 rwatch my_global_flag # 读写都看 awatch my_global_flag在 VS Code 里可以在变量面板右键选择数据断点部分调试适配器支持或者直接在 Debug Console 里敲上面的命令。命中之后栈回溯一下就能看到是谁写的。提示观察点数量只有 2 个而且用的时候会拖慢执行速度定位完记得删掉。另外观察点依赖总线访问DMA 直接写内存的操作在某些实现下不一定能触发这点要有心理准备。5.5 GDB 命令行还是有用的别完全丢掉图形界面覆盖了八成场景剩下两成还得靠命令行。常用的几个我列一下调试控制台里直接敲命令作用info registers看所有内核寄存器bt/bt full看调用栈full 带局部变量x/16wx 0x20000000以 16 进制看 16 个字的内存p/x *(uint32_t*)0x4001080C按地址读寄存器info breakpoints列出所有断点monitor reset halt让 OpenOCD 复位并停住monitor flash write_image erase xxx.bin 0x8000000手动烧录set var i 0运行中改变量值disassemble /m main混合显示源码和反汇编monitor开头的命令是直接透传给 OpenOCD 的不走 GDB 逻辑。set var改值这个功能太实用了比如你想跳过一段初始化直接验证后面的流程改个标志位就行不用重编译。6. HardFault 现场还原从一片空白到定位到行6.1 先把栈帧结构刻在脑子里HardFault 让人头疼是因为异常发生时 CPU 已经跳到了中断向量你看不到是谁触发的。好消息是 Cortex-M 在进异常前会自动把 8 个寄存器压栈这 8 个值就是现场。压栈顺序从低地址到高地址R0、R1、R2、R3、R12、LR、PC、xPSR。其中PC 就是出错的那条指令地址LR 是出错前的返回地址xPSR 的最低位能看出用的是 MSP 还是 PSP。但你得先知道这些值压在哪了。这就要看 LR 寄存器在异常里的值也就是 EXC_RETURNEXC_RETURN 值含义0xFFFFFFF1返回 Handler 模式用 MSP无 FPU 上下文0xFFFFFFF9返回 Thread 模式用 MSP无 FPU 上下文0xFFFFFFFD返回 Thread 模式用 PSP无 FPU 上下文0xFFFFFFE1/E9/ED对应上面三种但有 FPU 上下文多了 S0-S15 等不带 FPU 的情况下栈帧正好是 32 字节带 FPU 会多 72 字节18 个字这个偏移算错读出来的 PC 就是一坨垃圾。6.2 一段可以直接贴进工程的解码代码与其每次手工算不如在 HardFault 处理函数里把现场打出来#include stdint.h #include stdio.h void hardfault_report(uint32_t *stack) { uint32_t cfsr *(volatile uint32_t *)0xE000ED28; uint32_t hfsr *(volatile uint32_t *)0xE000ED2C; uint32_t mmfar *(volatile uint32_t *)0xE000ED34; uint32_t bfar *(volatile uint32_t *)0xE000ED38; printf(R0 0x%08lX\r\n, stack[0]); printf(R1 0x%08lX\r\n, stack[1]); printf(R2 0x%08lX\r\n, stack[2]); printf(R3 0x%08lX\r\n, stack[3]); printf(R12 0x%08lX\r\n, stack[4]); printf(LR 0x%08lX\r\n, stack[5]); printf(PC 0x%08lX -- 出错位置\r\n, stack[6]); printf(PSR 0x%08lX\r\n, stack[7]); printf(CFSR 0x%08lX\r\n, cfsr); printf(HFSR 0x%08lX\r\n, hfsr); if (cfsr (1u 1)) printf(DACCVIOL: 数据访问违例\r\n); if (cfsr (1u 9)) printf(PRECISERR: 精确总线错误\r\n); if (cfsr (1u 10)) printf(IMPRECISERR: 非精确总线错误\r\n); if (cfsr (1u 16)) printf(UNDEFINSTR: 未定义指令\r\n); if (cfsr (1u 24)) printf(UNALIGNED: 非对齐访问\r\n); if (cfsr (1u 25)) printf(DIVBYZERO: 除零\r\n); if (cfsr (1u 15)) printf(BFAR 有效, 出错地址 0x%08lX\r\n, bfar); if (cfsr (1u 7)) printf(MMFAR 有效, 出错地址 0x%08lX\r\n, mmfar); }配套的桩函数顺序别搞错__attribute__((naked)) void HardFault_Handler(void) { __asm volatile ( tst lr, #4 \n ite eq \n mrseq r0, msp \n mrsne r0, psp \n b hardfault_report\n ); }关键是tst lr, #4这一句判断 EXC_RETURN 的 bit2为 0 说明压的是 MSP为 1 是 PSP。如果用了 FreeRTOS任务里出的错几乎都是在 PSP 上这个判断能省你半小时。6.3 拿到 PC 之后怎么找对应的代码行有 PC 值就等于有了答案的一半。三种定位方式按方便程度排序第一种arm-none-eabi-addr2linearm-none-eabi-addr2line -e build/MyProject.elf -f -C 0x08000A3C输出会直接告诉你文件名、行号、函数名。这是我用得最多的。第二种arm-none-eabi-objdump -d反汇编之后搜地址能看到出错指令本身是什么比如是一条ldr从空指针偏移读数据。第三种在 GDB 里info line *0x08000A3C。拿到行号之后回头看 CFSR 的位。如果是PRECISERR加 BFAR 有效基本可以确定是非法地址访问比如访问了未初始化的指针。如果是UNDEFINSTR通常是函数指针跳飞了或者栈被踩导致返回地址错乱。如果是IMPRECISERR写操作往往是异步提交的出错地址不准得靠 BFAR 之外的手段这时候观察点或者缩小范围二分法更管用。7. 调试信息别打断实时性SWO、ITM 和串口日志的老实做法7.1 printf 重定向三条路的对比方式占用引脚速度是否影响实时性探针要求串口 printfTX 一根中等受波特率限制阻塞式会明显拖慢无半主机模式无用调试通道慢非常影响每条几毫秒需要调试器挂着ITM/SWO一根 SWO快影响小探针必须支持 SWO半主机模式semihosting看着优雅实际性能很差一次printf可能花掉几毫秒在有实时性要求的地方基本不能用。我只有在启动阶段打几条版本信息时才用它。串口是最通用的配合串口调试助手就能看。要点是别用阻塞式发送改成 DMA 或者中断发送把格式化好的字符串丢进环形缓冲区。缓冲区满了就丢数据别等——等就意味着你打断了业务逻辑的时序。7.2 ITM/SWO 值得花时间配一次ITM 是 Cortex-M 内核自带的调试组件往特定的激励端口写数据数据会通过 SWO 引脚送到调试器完全不需要占用 CPU 的等待时间对内核时钟的依赖有限。代码里这样写static inline void itm_send_char(char c) { while (*(volatile uint32_t *)0xE0000E00 0) { } /* 等端口就绪 */ *(volatile uint32_t *)0xE0000E00 (1u 24) | c; /* 1 号激励端口 */ }Cortex-Debug 的配置里加上swoConfig: { enabled: true, swoFrequency: 2000000, source: probe, decoders: [ { type: console, label: ITM, port: 0, encoding: ascii } ] }swoFrequency要跟芯片侧配的 SWO 时钟一致这个值算错就是一堆乱码很多人卡在这。另外要老实说明大量廉价的 ST-Link V2 山寨探针不支持 SWO会报SWO not supported。想要这个功能ST-Link V3 或者 J-Link 是更省事的选择。买之前先确认别配了半天发现硬件不行。7.3 日志同时打屏和落盘调试复杂问题时屏幕上的日志滚太快来不及看。VS Code 这边有个实用做法把 Cortex-Debug 的输出重定向到文件或者直接用tee把串口日志同时打到终端和文件# 假设串口设备是 /dev/ttyUSB0 stty -F /dev/ttyUSB0 115200 raw -echo cat /dev/ttyUSB0 | tee -a ./logs/run_$(date %Y%m%d_%H%M).log这样一边在终端实时看一边留档事后可以拿日志去跟 AI 工具一起分析。跟上位机联调的时候也类似比如协议走 Modbus一边开着协议调试工具发报文一边把 MCU 侧的收发日志落盘两边一对照问题基本藏不住。提示日志里打印时间戳比打印内容更重要。加一个基于 DWT 的微秒级计时出问题时能看出是超时还是逻辑分支走错了。DWT 的 CYCCNT 寄存器打开很简单几行代码的事收益很大。8. FreeRTOS 场景下调试的姿势要变一变8.1 让调试器认识任务裸机程序里bt出来的调用栈是一条直线。跑了 FreeRTOS 之后每个任务有自己的栈主调用栈只到prvTaskExitError之类的调度器桩函数看起来毫无意义。Cortex-Debug 有 RTOS 感知能力配置项大致是这样rtos: FreeRTOS配好之后调试侧边栏会出现任务列表能直接看到每个任务的名字、状态、优先级、当前栈指针。切换栈去看某个任务的局部变量比在裸栈里瞎找快得多。原理上它是通过读取pxCurrentTCB这个全局符号再顺着pxTopOfStack去解析每个任务的栈帧。所以前提是符号表里有这些名字编译器不能把它们优化掉。如果你的工程里pxCurrentTCB被定义在 C 文件里而没加volatile某些优化等级下调试器读到的值可能不准。这个坑不常见但真实存在遇到任务列表是空的可以先排查这一项。8.2 栈溢出不检测它就等着随机崩溃FreeRTOS 提供两种栈溢出检测模式模式一是切换任务时检查栈指针是否越界模式二是在栈末尾填魔数0xA5切换时检查最后一个字节是否还是0xA5。模式二更灵敏但更慢。我一般调试期把configCHECK_FOR_STACK_OVERFLOW设为 2同时实现钩子函数void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { (void)xTask; taskDISABLE_INTERRUPTS(); printf(STACK OVERFLOW: %s\r\n, pcTaskName); for (;;) { } }运行期还可以主动查水位找出哪个任务快撑不住了UBaseType_t watermark uxTaskGetStackHighWaterMark(NULL); /* 当前任务 */返回值是历史最小剩余栈空间单位是字Word乘以 4 才是字节。小于 32 个字就得警惕了。排查这类问题的顺序我一般是先怀疑局部大数组、再怀疑printf的格式化缓冲、最后怀疑递归调用。8.3 在任务里打断点别被时序骗了断点会停住整个内核FreeRTOS 的调度器也停了。这带来一个后果你看到的状态是冻结的跟真实运行时不一样。表现最典型的是看门狗复位——断点停久了独立看门狗照样跑等你放行的时候芯片已经被复位了。所以调试带看门狗的程序要么先把看门狗关了要么用调试器把看门狗冻结部分芯片支持 DBGMCU 里的冻结位。另一个是通信超时。你在从机任务里打了个断点主机那边等不到响应就超时重发了放行之后你收到的报文跟预期完全不一样很容易误判成协议实现有问题。我一般在这种场景下改用条件断点只在特定条件下才停下来或者干脆改用日志追踪。9. 把 AI 接进调试回路我实际在用的几个场景和边界这一节是这个系列的重点也是我最近半年变化最大的工作方式。强调一点AI 在这里是加速器不是替代品。它能把你从看不懂报错到知道往哪查的时间从半小时压到两分钟但它给的每一个寄存器地址、每一个位定义都要拿参考手册核对。9.1 让 AI 读 OpenOCD 的报错日志OpenOCD 的报错信息密度极低像Error: jtag status contains invalid mode value - communication failure这种新手完全没法下手。我的做法是把完整日志、launch.json、以及探针型号和芯片型号一起给它然后要求它做一件事列出最可能的三个原因并按排查成本从低到高排序。提示词大概这样写下面是一段 OpenOCD 的完整输出和我的 launch.json 配置。 硬件是 STM32F103C8T6 最小系统板探针是 ST-Link V2。 要求 1. 指出日志里第一个真正出错的环节不要复述后面的连锁错误 2. 按排查成本从低到高给出最多 3 个可能原因 3. 每个原因给出具体的验证命令或操作不要给泛泛的建议 4. 如果信息不足以判断直接说缺什么信息不要猜 日志 粘贴完整日志要求它不要复述连锁错误很重要因为 OpenOCD 一旦第一步失败后面会刷出十几行无关报错AI 很容易被带偏给你一堆不相关的建议。限定输出格式之后质量差别很大。9.2 生成和校验配置文件launch.json、tasks.json、c_cpp_properties.json 这些东西结构固定但字段多写错了不报错只是不生效排查起来很烦。我现在的习惯是让 AI 生成初稿然后自己核对三个点第一路径是否存在。AI 经常会编一个看起来合理但实际不存在的路径比如interface/stlink-v2-1.cfg。用之前ls一下 OpenOCD 的 scripts 目录。第二device字段和 SVD 是否匹配。STM32F103C8和STM32F103C8T6在不同版本的调试服务器里识别情况不一样有的要写完整型号有的要写系列名。第三preLaunchTask对应的任务名是否和 tasks.json 里的label完全一致。就一个字母之差调试就起不来。9.3 让 AI 帮你写现场解码脚本前面那段 HardFault 解码代码逻辑不复杂但容易写错位。我现在的做法是把 CFSR 的位定义直接从参考手册复制位表格连同我想要的输出格式一起给它让它生成代码然后我自己核对位偏移。核对的重点是 CFSR 被拆成 MMFSR、BFSR、UFSR 三个部分位偏移是连续的UFSR 的 UNDEFINSTR 是 bit16DIVBYZERO 是 bit25这两个数字错了整个判断就废了。同样的方法适合写 GDB 的 Python 脚本。比如你想在 GDB 里加一个命令一键打印所有任务的水位用 GDB 的 Python API 写起来很啰嗦但让 AI 生成一版再改几分钟的事。9.4 什么时候我绝对不信 AI 的答案必须说出来不然会误导人。寄存器绝对地址一定要核对。AI 对0x40010800是 GPIOA 基址这种常见值记得很准但对冷门外设或者新系列芯片编出来的地址看起来很合理实际是错的。核对方式很简单查芯片参考手册的存储器映射表或者查厂商的头文件里GPIOA_BASE之类的宏。库函数的参数顺序也容易错。HAL 库的HAL_UART_Transmit参数是(huart, pData, Size, Timeout)AI 有时候会把 Size 和 Timeout 搞反编译能过但行为完全不对。中断优先级和 NVIC 相关的建议要谨慎。AI 经常给出设置优先级为 0 最高这样的建议但没考虑你用的是哪个优先级分组以及 FreeRTOS 会占用最低几个优先级。这类建议必须结合你自己的工程配置来判断。我的判断标准很简单AI 给的结论如果能用一条命令或者一次观察验证就大胆用如果需要它保证正确而我无法验证就老老实实查手册。最后分享两个我踩过之后才养成的小习惯。一个是每次调试前先git status看一眼确认没有未提交的改动因为调试过程中你会想改代码试一下改完忘了回退第二天就分不清哪个版本是好的了。另一个是给每个调试会话留个debug_notes.md把当时的现象、试过什么、什么有效记下来重复问题的排查时间能压缩到原来的十分之一——这个习惯比任何工具都值钱。