MCU硬件调试与逻辑分析仪实战工程 - 第3节
3. 逻辑分析仪入门
调试MCU，说白了就是让代码“停下来给你看”。
怎么停？靠断点。怎么走？靠单步。这两个基本功要是没练扎实，后面RTOS调试根本玩不转。我见过不少工程师，拿着几千块的调试器，只会按全速运行和暂停，遇到问题就一脸懵——嗯，咱们今天就把这事彻底讲透。
硬件断点 vs 软件断点
先问个问题：你往IDE里点一下行号旁边那个小红点，到底发生了什么？
答案取决于你用的调试器。市面上主流调试器（J-Link、ST-Link、DAP-Link）都支持两种断点机制：
| 特性 | 硬件断点 | 软件断点 |
|---|---|---|
| 实现原理 | 利用CPU的调试寄存器（如FPB、DWT） | 在RAM/Flash中插入BKPT指令 |
| 数量限制 | 通常2~8个（取决于芯片） | 几乎无限 |
| 适用位置 | Flash、RAM均可 | 仅限RAM（Flash需先擦写） |
| 执行速度 | 无额外开销 | 有指令替换开销 |
| 掉电保持 | 不保持 | 不保持 |
核心结论：硬件断点靠芯片内部寄存器，不修改代码；软件断点靠往代码里塞特殊指令。前者金贵但干净，后者廉价但有副作用。
我在项目中遇到过最典型的坑：在Flash里设了十几个断点，结果调试器报错“无法设置断点”。为什么？因为芯片的Flash控制器不支持在运行时改写Flash内容，软件断点根本写不进去。解决办法很简单——把那段代码放到RAM里跑，或者改用硬件断点。
硬件断点的底层原理
以ARM Cortex-M系列为例，硬件断点靠的是FPB（Flash Patch and Breakpoint）单元。FPB里有若干个比较器，每个比较器存一个地址。当CPU取指地址命中比较器时，就触发断点异常。
说白了，就是芯片内部有个“地址监控器”。
Cortex-M3/M4通常有6个硬件断点，M0/M0+只有4个。够用吗？大部分场景够。但如果你在RTOS里同时给多个任务设断点，很快就用完了。
我的习惯：关键路径用硬件断点，普通调试用软件断点。硬件断点留给那些“必须精确命中”的场景，比如中断服务函数入口、临界区保护代码。
软件断点的陷阱
软件断点本质是往目标地址写一条BKPT指令（0xBE00）。CPU执行到BKPT时触发异常，调试器接管控制。
听起来简单，但有两个坑：
- Flash写入问题：很多MCU的Flash不能边执行边写。你设断点时调试器要暂停CPU、擦除Flash扇区、写入BKPT、再恢复执行——这个过程如果掉电或通信中断，Flash内容就坏了。
- 校验和失效：如果代码有CRC校验，软件断点会破坏校验值。我吃过这个亏——产品跑着跑着突然复位，查了两天才发现是调试时留下的软件断点没清干净。
避坑指南：我曾经在客户现场调试，用软件断点定位一个偶发死机问题。设了断点后问题不再复现，去掉断点又出现。后来发现是软件断点改变了Flash读取时序，恰好避开了硬件Bug。嗯，从那以后我养成了习惯——怀疑时序问题时，优先用硬件断点。
单步跳过/步入/步出
断点让你停下来，单步让你慢慢走。但“走”的方式有讲究。
三种单步模式
| 模式 | 行为 | 典型场景 |
|---|---|---|
| Step Over（跳过） | 执行当前行，遇到函数调用时一口气执行完 | 确认函数返回值是否正确，不关心内部实现 |
| Step Into（步入） | 进入函数内部，逐行执行 | 排查函数内部的逻辑错误 |
| Step Out（步出） | 执行完当前函数剩余部分，返回到调用处 | 发现进错函数了，或者函数前半段没问题 |
你想想看，这三个操作背后其实都是同一个机制——临时断点。调试器在你指定的“下一行”或“函数返回处”设一个临时硬件断点，然后全速运行，命中后自动清除。
关键点：单步执行依赖硬件断点。如果你的硬件断点用完了，单步会失败。这就是为什么RTOS调试时经常出现“单步失灵”的情况——断点资源被任务切换占用了。
单步的实战技巧
我个人习惯是：
- 跳过用于验证流程，比如检查if-else分支是否走对
- 步入用于深挖，比如怀疑某个函数内部有指针越界
- 步出用于快速跳出，比如发现某个循环要跑1000次，赶紧出来
但要注意：单步执行会改变时序。你在单步时，外设（UART、SPI、定时器）还在全速跑。我曾经单步调试一个I2C驱动，每步都停一下，结果从设备超时了——因为I2C时钟在单步期间没人管。
建议：调试外设驱动时，尽量用断点+全速运行，少用单步。单步更适合纯逻辑代码，比如协议解析、状态机、算法。
在RTOS中调试任务
RTOS调试是真正的分水岭。裸机调试你只需要关心一个main函数，RTOS里同时跑着五六个任务，断点一停，你都不知道当前在哪个任务里。
RTOS调试的三大难点
- 断点命中时机不确定：你给函数A设了断点，但任务A可能几秒才跑一次，你等得心焦。
- 单步会触发任务切换：单步执行时，如果时间片到了，调试器会跳到另一个任务里，你一脸懵。
- 断点资源竞争：RTOS内核本身也在用调试特性（比如统计任务执行时间），可能和你的断点冲突。
RTOS调试的实用方法
我调试RTOS项目时，一般按这个流程走：
- 第一步：确认任务是否在跑。在任务入口函数设断点，全速运行，看能不能命中。命不中？检查任务创建是否成功、优先级是否被抢占。
- 第二步：定位任务卡死。在任务循环体里设断点，单步执行几轮，看哪个API调用没返回。常见原因是信号量获取超时、队列发送阻塞。
- 第三步：检查任务栈溢出。RTOS内核通常有栈溢出检测钩子，在这个钩子里设断点。一旦命中，说明某个任务栈给小了。
核心技巧：利用RTOS的调试钩子。FreeRTOS有configASSERT()，uC/OS有OS_CFG_DBG_EN。把这些宏打开，很多问题在调试阶段就能暴露出来。
RTOS调试的断点策略
硬件断点有限，怎么分配给多个任务？我的做法是：
| 优先级 | 断点用途 | 说明 |
|---|---|---|
| 1 | 任务入口 | 确认任务是否被调度到 |
| 2 | 临界区 | 检查关中断是否导致死锁 |
| 3 | 错误处理 | 捕获异常返回、断言失败 |
| 4 | 业务逻辑 | 具体功能调试 |
如果硬件断点不够，可以用条件断点——但条件断点本质是软件断点+表达式判断，执行速度会变慢。我一般只在RAM里跑代码时用条件断点。
避坑指南：我曾经在FreeRTOS里调试一个优先级反转问题。给低优先级任务设了断点，结果高优先级任务一直抢占CPU，断点根本停不下来。后来我在调度器里设断点，每次任务切换都停一下，才看清优先级的变化过程。嗯，从那以后我学会了——RTOS调试，断点要设在“调度边界”上。
RTOS调试的SVG流程图
下面这张图展示了RTOS调试时，断点与任务调度的关系：
RTOS调试的终极武器：Trace
如果断点和单步搞不定，别硬撑。用逻辑分析仪抓RTOS的调试引脚输出，或者用SEGGER的SystemView这类工具，能看到任务切换的全过程。
我调试一个多任务死锁问题时，断点根本停不下来——因为死锁是概率性的。后来用逻辑分析仪抓了任务切换的GPIO波形，一眼就看出两个任务在互相等信号量。嗯，有些问题，靠断点解决不了，得靠“看全局”。
我的建议：在RTOS项目初期，就给每个任务分配一个调试GPIO。任务切换时翻转电平，逻辑分析仪一抓，调度情况一目了然。这个习惯帮我省了至少一半的调试时间。