嵌入式与前端联合Debug实战：从Vue到STM32的底层故障定位-育师

1. 从“debug学习记录1”这个标题里，我看到了什么

看到“debug学习记录1”这四个字，第一反应不是技术细节，而是——这大概率是个刚踩进坑里、还没来得及喘口气的开发者。不是在写文档，不是在做汇报，就是在某个深夜或清晨，盯着IDE里红色的断点、闪烁的变量窗口、突然中断的串口日志，一边敲键盘一边随手记下的第一行笔记。它没标题党，不炫技，甚至没标点，但恰恰是这种“未完成态”，暴露了最真实的学习切口：debug不是一门课，而是一场持续发生的现场救援。

我带过不少嵌入式和前端新人，发现一个共性现象：他们能背出Vue响应式原理、能默写STM32时钟树配置、能写出漂亮的React Hook，但一旦程序跑飞、变量值突变、界面白屏、单片机反复重启，立刻陷入“看得到现象，找不到源头”的瘫痪状态。这时候翻文档？文档里写的都是“正常流程”；查API？API只告诉你“该返回什么”，不告诉你“为什么没返回”。真正救命的，反而是某次调试时偶然发现的寄存器值异常、某行被忽略的console.log输出、某个快捷键组合触发的意外堆栈快照——这些碎片，才是debug能力的原始积累。

所以这篇记录，不讲“什么是debug”，不列“debug十大技巧”，而是直接钻进你此刻正面对的真实战场：Vue组件渲染卡死时怎么定位响应式链断裂点；Keil里Watchdog超时导致MCU硬复位，如何在复位前抓取最后一帧寄存器快照；IntelliJ IDEA报“fatal error in native method”却无堆栈，怎么绕过JVM层直击本地库崩溃现场；瑞芯微平台修改DEBUG串口后printf全失效，问题到底出在引脚复用冲突还是UART驱动初始化顺序；VSCode调用Keil5进行ARM Cortex-M调试时，为何断点总跳过、变量显示为 ……这些不是理论题，是你的开发环境里正在发生的“故障事件”。

关键词里没有给出具体技术栈，但热搜词已经画出了清晰的作战地图：前端（Vue）、嵌入式（Keil/STM32/瑞芯微）、Java/Android（IDEA）、跨工具链（VSCode+Keil）。这意味着，真正的debug能力，必须跨越IDE表层操作，深入到编译器行为、运行时内存布局、硬件外设时序、工具链协同机制这些“看不见的底层”。接下来的内容，就是按这个逻辑展开——不教你怎么点菜单，而是带你理解：为什么点下那个F8，CPU会停在这一行；为什么改了串口引脚，printf就没了回声；为什么加了个断点，程序反而跑得更慢甚至崩溃。这些，才是“学习记录1”背后真正值得记下的第一课。

2. Vue打debug：别只盯着console.log，先搞懂DevTools的“时间旅行”机制

很多人说“Vue打debug”，第一反应就是console.log(this.xxx)，然后刷新页面看输出。这没错，但效率极低，尤其当问题出现在异步更新、computed依赖链、或者父子组件通信中时，log像撒胡椒面，根本抓不住关键节点。Vue DevTools的debug能力，核心不在“打印”，而在“时间旅行”——它把整个响应式系统的状态变化，变成了可回溯、可暂停、可干预的录像带。

2.1 响应式追踪的本质：Dep与Watcher的双向绑定

Vue 2的响应式基于Object.defineProperty，Vue 3则用Proxy，但核心机制一致：每个响应式数据（data、props、computed）背后都绑着一个Dep（依赖收集器），每个使用该数据的计算属性或模板渲染函数，都对应一个Watcher（观察者）。当你在模板里写{{ user.name }}，Vue编译器会生成一个渲染Watcher，并在执行过程中访问user.name——此时user.name的getter被触发，它会把当前Watcher添加到自己的Dep中。这就是“依赖收集”。

提示：打开Vue DevTools，切换到“Components”面板，点击任意组件，在右侧“Reactivity”标签页下，你能看到所有响应式属性及其关联的Watcher数量。如果某个属性Watcher数为0，说明它根本没被模板或computed引用，改了也不会触发更新——这是排查“数据变了但视图不动”的第一线索。

2.2 断点打在哪？打在“触发更新”的临界点，而非“赋值”瞬间

常见误区：在this.user.name = 'newName'这行打断点。问题在于，赋值操作本身很快，但后续的依赖通知、Watcher重新求值、虚拟DOM diff、真实DOM patch，才是耗时主体，也是bug高发区。正确做法是：

在Watcher的get方法入口打断点：打开DevTools的Sources面板，搜索watcher.js（Vue 2）或reactive.ts（Vue 3），找到Watcher.prototype.get或effect函数。这里才是响应式更新的“心脏起搏点”。当user.name被修改，所有依赖它的Watcher都会在此处重新执行get，触发render函数。
利用DevTools的“Render Watcher”功能：在Components面板选中组件，右上角点击“…” → “Debug render watcher”。这会在该组件的render函数入口自动加断点。此时刷新或触发更新，程序会停在render开始处，你可以逐行步入，观察this.xxx的值如何被读取、计算、拼接成VNode。
捕获异步更新的“nextTick”时机：Vue的DOM更新是异步的，放在microtask队列。如果你在this.user.name = 'newName'后立即查DOM，肯定查不到。想确认更新是否完成，不要setTimeout，而是在DevTools Console里输入await Vue.nextTick()（Vue 2）或await nextTick()（Vue 3），再查DOM。更进一步，在Sources里搜索nextTick，找到flushCallbacks函数，在其内部打断点，就能看到所有pending的DOM更新任务是如何被批量执行的。

2.3 实战案例：Computed属性“忽明忽暗”，如何定位依赖污染？

现象：一个fullNamecomputed属性，有时返回正确值，有时返回undefined，且无规律。代码看似简单：

computed: { fullName() { return this.firstName + ' ' + this.lastName; } }

排查链路：

第一步：在DevTools Components面板，选中该组件，看fullName的Reactivity详情。发现其Dep里除了firstName、lastName，还多了一个userInfo对象——这明显不合理。
第二步：检查userInfo是否被意外访问。在fullName函数内加debugger，运行后停住，查看调用栈。发现某次调用时，fullName被一个第三方库的formatUser函数间接调用，而该函数内部访问了this.userInfo.avatar。
第三步：根源在于formatUser函数被定义在组件methods里，但被错误地当作computed使用（比如在template里写了{{ formatUser() }}）。由于methods不是响应式，但formatUser内部访问了userInfo，导致userInfo的getter被触发，其Dep错误地收集了fullName的Watcher。
解决方案：将formatUser移出methods，改为纯函数（不依赖this），或确保它只在created/mounted等钩子中调用，绝不让它参与响应式依赖收集。

注意：Vue 3的Composition API中，computed(() => ...)的依赖收集更严格，但watch的immediate: true选项若配合副作用函数，同样可能引发类似污染。原则不变：任何访问响应式数据的代码路径，都可能成为依赖收集的入口，必须审视其调用上下文。

3. Keil STM32 Watchdog Debug：在MCU复位前，抢出最后一帧“遗言”

Watchdog（独立看门狗IWDG或窗口看门狗WWDG）是嵌入式系统里最“沉默的杀手”。它不报错，不抛异常，只在超时后冷酷地拉低NRST引脚，让MCU硬复位。你看到的只是“程序莫名重启”，日志戛然而止，连个错误码都不留。传统debug手段（如串口printf）在此失效——因为复位发生得太快，缓冲区里的日志根本来不及发送。真正的Watchdog debug，核心目标只有一个：在复位发生的毫秒级窗口内，捕获CPU寄存器状态、RAM关键变量、以及最重要的——Watchdog控制寄存器（IWDG_KR、IWDG_RLR）的实时值。

3.1 硬件级断点：利用Cortex-M的“复位向量捕获”机制

STM32的复位向量（Reset Handler）地址是0x00000004，但Keil默认在此处不设断点，因为复位后所有寄存器重置，断点会丢失。正确做法是启用Keil的“Reset Handler Breakpoint”：

在Keil µVision中，点击“Debug” → “Start/Stop Debug Session”。
进入Debug模式后，点击“View” → “Registers” → 打开“Core Peripherals” → “NVIC”。
在“System Control Block (SCB)”下，找到AIRCR寄存器，将其VECTRESET位（bit 0）置1。这会强制CPU在复位后进入调试状态，而非直接执行Reset Handler。
更可靠的是，在startup_stm32fxxx.s文件中，找到Reset_Handler函数，在其第一行ldr r0, =_estack之前，插入bkpt #0指令（ARM汇编断点）。这样，每次复位，CPU都会停在此处，你可以从容查看所有寄存器。

3.2 关键寄存器快照：IWDG的“死亡倒计时”解码

Watchdog超时，本质是递减计数器（IWDG_RLR）归零。要确认是否真由WDT引起，必须在复位前读取：

IWDG_KR（Key Register）：写入0xCCCC启动，0xAAAA喂狗，0x5555停止。若复位前此值为0xAAAA，说明程序还在正常喂狗；若为0xCCCC，说明WDT已启动但未喂；若为0x5555，说明WDT被意外关闭（通常不是复位原因）。
IWDG_RLR（Reload Register）：决定超时时间。公式：Timeout = (RLR + 1) * 4 * (Prescaler) / LSI_Freq。LSI频率约32kHz，预分频器（IWDG_PR）默认为4（即4分频），则RLR=0xFFF对应约262ms超时。若RLR值异常小（如0x10），则超时仅几ms，极易误触发。
IWDG_SR（Status Register）：PVU（Prescaler Update Flag）和RVU（Reload Value Update Flag）为1时，表示预分频器或重装载值正在更新，此时写IWDG_KR无效。若复位前SR显示RVU=1，说明程序在更新RLR后未等待RVU清零就去喂狗，导致喂狗失败。

实操步骤：

在Keil Debug模式下，打开“View” → “Memory Windows”，地址栏输入0x40003000（IWDG基地址）。
查看IWDG_KR（偏移0x00）、IWDG_PR（0x04）、IWDG_RLR（0x08）、IWDG_SR（0x0C）的十六进制值。
若SR显示RVU=1，则需在修改RLR后，循环等待while(IWDG->SR & IWDG_SR_RVU);。
若RLR值过小，检查初始化代码：IWDG->RLR = 0xFFF;是否被执行？是否被其他代码覆盖？

3.3 软件级“遗言”：利用RAM备份寄存器（BKPSRAM）保存现场

STM32的BKPSRAM（Backup SRAM）在主电源掉电或复位时由VBAT供电保持数据。这是存放“遗言”的黄金位置：

// 在main()开头，启用BKPSRAM时钟并解锁 __HAL_RCC_BKPSRAM_CLK_ENABLE(); __HAL_RCC_PWR_CLK_ENABLE(); HAL_PWR_EnableBkUpAccess(); // 解锁备份域 // 定义全局结构体，存于BKPSRAM __attribute__((section(".backup_ram"))) typedef struct { uint32_t last_pc; // 最后PC值 uint32_t stack_top; // 栈顶地址 uint32_t wdt_rlr; // WDT重装载值 uint32_t wdt_sr; // WDT状态 } CrashInfo_t; CrashInfo_t* pCrash = (CrashInfo_t*)0x40024000; // BKPSRAM起始地址 // 在喂狗前，更新现场 void IWDG_Feed(void) { pCrash->last_pc = __get_PC(); pCrash->stack_top = __get_MSP(); pCrash->wdt_rlr = IWDG->RLR; pCrash->wdt_sr = IWDG->SR; IWDG->KR = 0xAAAA; // 喂狗 } // 复位后，在SystemInit()中读取 void SystemInit(void) { if (pCrash->wdt_sr & IWDG_SR_PVU) { // 检查是否WDT相关复位 printf("WDT Crash! PC=0x%08X, RLR=0x%04X\n", pCrash->last_pc, pCrash->wdt_rlr); } // 清空，避免下次误判 memset(pCrash, 0, sizeof(CrashInfo_t)); }

提示：BKPSRAM容量有限（通常4KB），且需VBAT供电。若无电池，可改用Flash的最后一页（需擦除编程，速度慢但持久）。关键是——不要等到复位后再想“刚才发生了什么”，而要在每一次关键操作（尤其是喂狗、中断退出、DMA传输完成）前，主动存档。

4. IDEA Debug Fatal Error in Native Method：绕过JVM屏障，直击C/C++层崩溃现场

IntelliJ IDEA报“Fatal Error in Native Method”，日志里只有# A fatal error has been detected by the Java Runtime Environment:和一长串hs_err_pid*.log文件路径，接着是SIGSEGV（段错误）或SIGABRT（中止信号）。这时，Java层面的断点、变量监视全部失效，因为崩溃发生在JVM调用的本地库（.so/.dll）里，JVM自身都来不及做完整堆栈。常规思路是查JNI代码，但更高效的做法是：把IDEA的Debugger当成一个轻量级GDB/LLDB前端，直接调试native代码。

4.1 配置Native Debug环境：让IDEA加载符号表

前提：你的native库必须是Debug版本（Linux下带.debug段，Windows下有.pdb文件）。

Linux/macOS：在IDEA中，Run→Edit Configurations→ 选择你的Application →Configuration标签页 → 勾选Enable native debugging。确保LD_LIBRARY_PATH包含native库路径，且库文件名匹配（如libmyjni.so）。
Windows：同上，勾选Enable native debugging，并确认.pdb文件与.dll同目录，且文件名一致（如myjni.dll对应myjni.pdb）。
关键一步：在Build→Edit Build Types→Debug→Compiler中，确保C/C++编译器参数包含-g（GCC/Clang）或/Zi（MSVC），生成调试符号。

4.2 定位崩溃点：从hs_err日志逆向解析

hs_err_pid*.log是破案关键。重点看三部分：

Current thread (0x00007f...):后的线程ID，对应native线程。
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000：说明访问了空指针（si_addr=0）。
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)：下面列出的C [libmyjni.so+0x1a2b]，0x1a2b是崩溃在so文件内的偏移地址。

将偏移地址转换为源码行：

# Linux下，用addr2line arm-linux-gnueabihf-addr2line -e libmyjni.so 0x1a2b # 输出类似：/path/to/src/jni_utils.c:42

若无符号表，objdump -d libmyjni.so | grep "1a2b:"可看到附近汇编指令，结合源码反推。

4.3 实战调试：在JNI函数入口设断点，逐步步入

假设崩溃在Java_com_example_MyClass_crashMethod：

在IDEA的Project视图中，找到对应的.c文件（如myclass.c），在Java_com_example_MyClass_crashMethod函数第一行设断点。
启动Debug（确保已勾选native debugging）。
当Java代码调用该JNI方法，IDEA会自动停在C函数入口。此时，你可以：
- 查看JNIEnv* env和jobject obj是否为NULL（JNI规范要求检查）。
- 使用env->GetDirectBufferAddress()获取ByteBuffer指针后，务必用env->GetDirectBufferCapacity()验证长度，避免越界读写。
- 对jstring，必须用env->GetStringUTFChars()获取C字符串，并在使用后调用env->ReleaseStringUTFChars()释放，否则内存泄漏。
若崩溃在第三方库（如OpenCV），无法修改源码，则在调用其API前，用valgrind --tool=memcheck（Linux）或Application Verifier（Windows）先行检测内存错误。

注意：JNI层崩溃常因“线程亲和性”问题。JNIEnv*只在创建它的线程有效。若在子线程（如pthread）中调用JNI，必须先用JavaVM->AttachCurrentThread()获取该线程的JNIEnv*，用完后DetachCurrentThread()。IDEA的native debugger能清晰显示当前线程ID，对比pthread_self()和JavaVM->GetEnv()返回值，可快速验证。

5. 瑞芯微修改DEBUG串口：引脚复用、驱动时序与printf的“静音”真相

瑞芯微（Rockchip）平台（如RK3399、RK3566）的DEBUG串口（通常是UART0或UART2）被修改后，printk或printf完全失效，串口助手收不到任何字符。这不是代码问题，而是芯片级资源冲突的典型表现。瑞芯微的UART模块高度集成，其TX/RX引脚往往与GPIO、I2C、SPI等复用，修改串口需同时协调引脚配置（PinMux）、时钟使能（Clock）、电源域（Power Domain）、以及驱动初始化顺序四大环节。

5.1 PinMux配置：一个引脚，两套寄存器

瑞芯微的引脚复用由两个寄存器组控制：

GRF_GPIO*_IOMUX（General Register File）：全局复用配置，决定引脚基础功能（GPIO/UART/I2C）。
SCH_GPIO*_IOMUX（Special Control Register File）：特殊功能配置，如UART的波特率、流控、红外模式。

常见错误：只改了GRF寄存器，把引脚设为UART功能，却忘了SCH寄存器里UART模块的使能位（如UART0_SCH_EN）。结果是引脚物理连通，但UART控制器根本没上电，自然无输出。

验证方法：

在U-Boot命令行，用md.l 0xff770000 10（RK3399 GRF基地址）查看GRF_GPIO0A_IOMUX（偏移0x00），确认bit[15:12]为0b0010（UART0_TX）。
再用md.l 0xff780000 10（SCH基地址）查看SCH_UART0_CTRL（偏移0x10），确认bit[0]（UART0_EN）为1。

5.2 Clock与Power Domain：UART的“生命维持系统”

瑞芯微采用多域电源管理，UART模块的时钟和电源由独立控制器管理：

Clock Gating：CRU_CLKGATE_CON寄存器（如RK3399在0xff760000）的CLK_UART0位（bit 16）必须为1，否则UART模块时钟被关闭，寄存器读写无效。
Power Domain：PMU_PWRMODE_CON寄存器（如RK3399在0xff730000）的PWR_UART0位（bit 8）必须为0（表示ON），否则UART模块断电。

调试技巧：在Kernel启动早期（early_printk阶段），通过rockchip_pmu_power_domain_on()函数确认Power Domain已开启；在uart-pl011.c驱动的pl011_probe()中，在clk_prepare_enable(uart->clk)后，用readl_relaxed(uart->port.membase + UART0_FR)读取FR寄存器（Flag Register），若返回0xFFFFFFFF，说明时钟未启或模块未供电。

5.3 驱动初始化顺序：谁先抢到UART的“控制权”

瑞芯微平台常存在多个UART驱动竞争同一硬件资源：

rockchip-rk3399-uart0.dtsi定义的serial@ff180000（UART0）。
rk808等PMIC芯片的uart@ff190000（UART2）。
用户自定义的&uart0节点，若status = "okay"，但clocks属性指向错误的clock provider，会导致驱动probe失败。

解决方案：

在DTS文件中，确保&uart0节点的clocks属性引用正确的clock phandle（如<&cru aclk_uart0>），且clock-names = "baud"。
在Kernel配置中，禁用冲突驱动：CONFIG_SERIAL_AMBA_PL011=y（必须启用），CONFIG_SERIAL_RK808=y（若不用RK808 UART则设为n）。

最关键：在arch/arm64/boot/dts/rockchip/rk3399-evb.dts中，确认chosen节点的stdout-path指向正确的UART alias：

chosen { stdout-path = "serial0:1500000n8"; // serial0 必须对应 &uart0 的 alias }; &uart0 { status = "okay"; rockchip,grf = <&grf>; // 其他属性... };

提示：修改DTS后，务必make dtbs重新编译设备树，并用fdtdump -s your.dtb | grep uart验证stdout-path是否生效。一个字节的DTS错误，就能让整个DEBUG串口静音。

6. VSCode中使用Keil5进行Debug：打通ARM Cortex-M的“跨IDE”调试链

VSCode作为编辑器，本身不提供ARM Cortex-M调试能力，它需要通过CMSIS-DAP、J-Link或ST-Link等调试适配器，调用Keil µVision 5（UV5）的ULINK或ARM DLL作为后端。但默认配置下，VSCode的cortex-debug插件与Keil5常出现“断点不命中”、“变量显示 ”、“无法查看外设寄存器”等问题。根源在于：VSCode只负责UI和协议转发，真正的调试逻辑、符号解析、内存映射，全由Keil的调试引擎执行，二者必须在“调试会话生命周期”上完全同步。

6.1 launch.json核心配置：指定Keil调试器路径与工程文件

VSCode的launch.json必须精确指向Keil安装目录和.uvprojx文件：

{ "version": "0.2.0", "configurations": [ { "name": "Keil Debug", "type": "cortex-debug", "request": "launch", "servertype": "keil", "cwd": "${workspaceFolder}", "executable": "./build/your_app.axf", // Keil生成的AXF文件 "device": "STM32F407VG", // 必须与Keil工程Device一致 "configFiles": [ "C:/Keil_v5/ARM/SEGGER/JLinkSettings.ini" // 若用J-Link ], "showDevDebugOutput": true, "svdFile": "./STM32F407.svd", // 外设寄存器定义文件 "overrideLaunchCommands": [ "monitor reset halt", "load", "monitor reset init" ] } ] }

关键点：

"servertype": "keil"：告诉cortex-debug插件，后端是Keil，而非OpenOCD或J-Link。
"executable"：必须是Keil编译生成的.axf文件，不是.hex或.bin。.axf包含完整的调试符号（DWARF）。
"device"：必须与Keil工程中Target页设置的Device完全一致（如STM32F407VG），否则Keil调试器无法加载正确的Flash算法。

6.2 符号加载失败：AXF文件的“调试信息”完整性检查

VSCode显示<optimized out>，90%原因是AXF文件缺少调试信息：

在Keil中，Options for Target→Output标签页 → 勾选Create Hex File（非必需）和Debug Information（必须！）。
C/C++标签页 →Misc Controls→ 添加--debug（ARMCC）或-g（GCC）。
编译后，在build/目录下，用fromelf --text -a your_app.axf命令查看是否有DW_TAG_subprogram等DWARF标签。若无，说明调试信息未生成。

6.3 外设寄存器不可见：SVD文件与Keil调试器的协同

VSCode的cortex-debug插件通过SVD文件（如STM32F407.svd）解析外设地址，但Keil调试器有自己的寄存器视图。要让二者一致：

在Keil中，View→Peripheral Registers，确认能正常显示RCC、GPIO等寄存器。
在VSCode中，Debug Console输入monitor reg，应返回类似R0 = 0x00000000的寄存器列表。
若VSCode外设视图为空，检查launch.json中的svdFile路径是否正确，且SVD文件版本与芯片型号匹配（如F407用STM32F407.svd，非F103）。

注意：Keil5的调试器（ULINK/ARM DLL）对多核（如Cortex-A7 + Cortex-M4）支持有限。若VSCode连接后提示No target connected，先在Keil中单独调试成功，再切换到VSCode。VSCode不是替代Keil，而是扩展Keil的编辑体验；真正的调试深度，仍取决于Keil调试引擎的能力。

7. 单片机Debug导致重启：那些你以为在调试，其实是在“触发”故障的陷阱

单片机调试时“越调越崩”，是嵌入式开发者最沮丧的体验。明明只是加了个断点、看了眼变量、单步执行了一行，系统就复位了。这不是运气差，而是debug操作本身改变了系统时序、功耗、或内存状态，无意中触碰了脆弱的临界点。这类问题，必须用“故障注入思维”来排查：把debug动作本身，当作一个可能的故障源。

7.1 断点陷阱：Flash断点 vs RAM断点的时序差异

ARM Cortex-M的断点有两种实现：

Flash断点：在Flash中替换指令为BKPT #0。由于Flash读取比RAM慢，CPU执行到断点时，流水线可能已预取后续指令，导致时序敏感操作（如SPI写时序、PWM占空比）错乱。
RAM断点：将代码拷贝到RAM执行，再设断点。速度更快，但占用RAM，且某些MCU（如STM32F0）RAM空间极小。

现象：在SPI发送函数中设断点，SPI总线出现异常脉冲，从机误响应，导致系统异常。解决方案：

在Keil中，Options for Target→Debug→Settings→Breakpoints→ 将Use Flash Breakpoints改为Use RAM Breakpoints。
或，将SPI发送函数用__attribute__((section(".ramfunc")))声明，强制链接到RAM。

7.2 变量监视的“幽灵写入”

IDE的Variables视图在后台会周期性读取变量内存地址。若该变量位于DMA传输的缓冲区（如uint8_t rx_buffer[256]），而DMA正在往其中写入数据，IDE的读取操作可能与DMA写入发生总线冲突，导致DMA控制器异常，进而触发HardFault。

验证方法：

在Keil中，View→Watch→ 右键变量 →Add to Watch Window，观察是否伴随系统异常。
临时关闭Watch窗口，改用Memory Window手动查看地址，问题消失，则确认是Watch机制引发。

规避策略：

对DMA缓冲区变量，不在Watch窗口添加，改用printf或LED闪烁输出关键状态。
在DMA传输完成中断中，设置一个标志位（如volatile bool dma_done = false;），在主循环中轮询此标志，再读取缓冲区。

7.3 单步执行的“时间膨胀效应”

单步执行（Step Over/Into）时，CPU每执行一条指令就暂停，等待调试器指令。这导致：

看门狗超时：喂狗代码被单步，WDT计数器跑满。
实时任务超期：FreeRTOS的vTaskDelay()基于SysTick，单步时SysTick中断被屏蔽，任务永远等不到延时结束。
通信超时：I2C/SPI的ACK等待、UART的接收超时，都在单步中被无限延长。

应对原则：

绝不单步进入WDT喂狗、SysTick Handler、通信超时处理等实时敏感代码。
在Keil中，Debug→Run to Cursor（Ctrl+F9）代替单步，让代码连续执行到光标处。
对于必须调试的实时代码，改用“条件断点”：右键断点 →Edit Breakpoint→ 设置条件SysTick->VAL < 1000，只在特定状态下暂停。

经验之谈：我曾调试一个电机控制环，单步时电机抖动，连续运行时平稳。最终发现，PID计算中的浮点运算在单步时因FPU状态寄存器未及时更新，导致计算溢出。解决方案是：在main()开头添加__set_FPSCR(0x00000000);强制清FPU状态，再开启调试。Debug不是万能的显微镜，它本身就是一个扰动源；高手的debug，是不断校准这个扰动，逼近真实系统行为的过程。