3. IDE调试基础：Keil与IAR的断点、窗口与故障定位
调试器这东西，说白了就是你的第二双眼睛。尤其在做裸机开发时，没有操作系统帮你打印日志，你全靠调试器跟芯片“对话”。
我个人习惯把调试分为三个层次：断得住、看得见、追得回。断点让你停在关键位置，Watch和Memory窗口让你看清现场，Call Stack帮你回溯来路。这三板斧用熟了，大部分Bug都能在十分钟内定位。
3.1 断点类型：硬件断点 vs 软件断点
很多新手以为断点就是点一下鼠标，其实Keil和IAR背后用了两种完全不同的机制。
| 对比项 | 硬件断点 | 软件断点 |
|---|---|---|
| 原理 | 利用CPU的调试寄存器，比较PC地址 | 在目标地址插入BKPT指令（0xBE00） |
| 数量限制 | STM32通常只有6个（F1/F4系列） | 理论上无限（受Flash擦写寿命限制） |
| 适用场景 | ROM/Flash中的代码、中断服务函数 | RAM中的代码、临时调试 |
| 副作用 | 无 | 修改了Flash内容，下载前需擦除 |
关键认知：硬件断点用完了怎么办？Keil会自动降级为软件断点，但如果你在Flash里设了软件断点，下次下载前必须全擦，否则断点残留会导致程序跑飞。
我在项目中遇到过一件事：一个同事在中断服务函数里设了8个断点，结果程序死活不触发。我过去一看，硬件断点只有6个，剩下2个自动变成了软件断点。但ISR在Flash里，软件断点写入时刚好碰到了Flash正在执行读操作——嗯，直接HardFault了。
我的习惯：在Flash代码中只用硬件断点，RAM调试时才用软件断点。Keil里可以在「Debug → Breakpoints」窗口手动指定类型，别全交给IDE自动选择。
3.2 Watch窗口：不只是看变量
Watch窗口谁都会用，但你真的用对了吗？
我见过太多人把整个结构体拖进Watch窗口，然后抱怨调试器卡死。Watch窗口每次刷新都会通过JTAG/SWD读取目标内存，如果你一次看太多变量，调试速度会急剧下降。
3.2.1 高效使用技巧
- 只关注关键变量：每次调试只拖2-3个最可疑的变量进去
- 使用类型转换：在Keil里可以写
(MyStruct*)0x20000100直接查看某个地址的结构体内容 - 利用Watch1和Watch2：我习惯把全局变量放Watch1，局部变量放Watch2，方便对比
- 注意优化影响：如果变量被优化掉了，Watch窗口会显示「
」。这时候要么加volatile，要么把优化等级降到-O0
我曾经踩过的坑：有一次调试一个串口DMA接收，Watch窗口里显示buffer数据是对的，但实际发送出去却是乱码。折腾了两小时才发现——Watch窗口读的是缓存地址，而DMA已经把指针移走了。说白了，Watch窗口看到的是你请求时的快照，不是实时流。
3.3 Memory窗口：裸机调试的杀手锏
Watch窗口看变量，Memory窗口看原始字节。这两者的区别，就像看菜单和看厨房——菜单告诉你菜名，厨房里才是真材实料。
我调试DMA、寄存器配置、环形缓冲区时，几乎全程盯着Memory窗口。因为Watch窗口会做类型解析，有时候反而掩盖了真实的内存布局。
3.3.1 常用操作
- 直接输入地址：比如
0x40011000看GPIOA的寄存器 - 修改内存值：右键选择「Modify Memory at...」，可以强制写入值来模拟外设行为
- 显示格式切换：我习惯用32位十六进制显示，一目了然
- 锁定刷新：在IAR里可以勾选「Live Watch」，Keil里按F5持续刷新
实战案例：有一次怀疑SPI的TXE标志位没置位，我在Memory窗口盯着 0x40013000（SPI1的SR寄存器地址），每按一次F5看bit1有没有变。如果靠Watch窗口看结构体成员，中间隔了好几层封装，反而容易漏掉细节。
3.4 Call Stack窗口：回溯调用链
Call Stack窗口在裸机调试中经常被忽略。很多人觉得裸机程序没有函数调用栈，其实不然——只要你的代码用了函数嵌套调用，Call Stack就能帮你回溯。
但要注意一点：Call Stack依赖栈帧的完整性。如果栈被踩坏了，Call Stack显示的内容就是垃圾。
3.4.1 什么时候必须用Call Stack
- HardFault定位：停在异常处理函数时，Call Stack能告诉你是从哪个函数跳进来的
- 递归调用检查：看栈深度是否超出预期
- 任务切换调试：在裸机轮询架构中，看当前执行到哪个模块
我的经验：如果Call Stack显示不全，先检查SP指针是否在有效范围内。有时候栈溢出导致SP跑飞，Call Stack就废了。这时候我会先看Registers窗口里的SP值，再在Memory窗口里手动解析栈内容。
3.5 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以把它当作调试时的检查清单：
3.6 三个窗口的配合实战
光知道每个窗口怎么用还不够，你得学会让它们打配合。我总结了一个简单的调试流程：
- 先设断点：在怀疑的代码行设硬件断点（优先）
- 跑起来：全速运行，等断点触发
- 看Call Stack：确认当前调用路径是否预期
- 查Watch：看关键变量值是否合理
- 翻Memory：如果变量值不对，去Memory窗口看原始内存布局
举个例子：有一次我调试一个环形缓冲区的读写指针不同步问题。先在写入函数设断点，Call Stack显示调用来源正确；Watch窗口里写指针值也对；但读指针始终落后。最后在Memory窗口里一看——缓冲区起始地址写错了，数据写到了隔壁数组里。如果只看Watch窗口，根本发现不了这个地址偏移问题。
3.7 避坑指南
我曾经犯过的错：
- 在中断里设软件断点，导致中断响应延迟，误判为时序问题
- Watch窗口里看全局变量，忘了加volatile，编译器优化后值永远不变
- Memory窗口修改了寄存器值，没注意修改的是只读位，导致外设状态异常
- Call Stack显示不全时没检查栈溢出，浪费了半天查逻辑
调试这事，说白了就是经验积累。你踩过的坑越多，下次定位就越快。这三个窗口用好了，至少能覆盖80%的裸机调试场景。剩下的20%，咱们后面几章慢慢聊。