4. 断点体系与故障现场捕获

在嵌入式调试中，断点是最常用的“时间冻结”手段，但不同断点类型的实现机制、资源占用和适用场景差异很大。理解这些差异，才能在故障定位时选对断点、放对位置，并在命中后正确保存现场。

一、四类断点的实现机制与资源约束

硬件断点依赖 CPU 内部的断点比较单元（如 Cortex-M 的 FPB 单元）。以 Cortex-M3/M4 为例，通常提供 6 个指令断点比较器和 2 个字面量比较器。硬件断点将目标地址写入比较寄存器，CPU 取指时若地址匹配则触发调试异常。它的关键优势是不修改目标代码，因此可以下在 Flash 中的任意指令上，且不占用 RAM。缺点是数量有限，且地址必须对齐到指令边界。

软件断点通过将目标指令的首字节替换为断点指令（ARM 上通常是 BKPT，编码为 0xBE00）实现。命中时 CPU 进入调试状态，调试器再把原指令写回并单步执行一次，然后重新写入断点。软件断点数量几乎不受限，但要求目标地址位于可写存储器（RAM 或可擦写 Flash），且会短暂修改代码内容。在只读 Flash 上，Ozone 通常需要借助 Flash 断点（Flash Breakpoint）机制，由调试器在命中后动态恢复，效率低于硬件断点。

数据断点（Watchpoint）监视的是数据访问而非取指。Cortex-M 的 DWT 单元提供 4 个数据观察点比较器，可配置为监视读、写或读写。当某条指令访问了指定地址范围时触发。数据断点非常适合定位“变量被意外改写”这类问题——例如某个全局状态机变量在中断中被篡改，用数据断点监视其写操作，命中时调用栈会直接指向肇事代码。

条件断点是在上述断点基础上附加布尔表达式。硬件条件断点由 DWT 的比较器直接支持（如仅当地址匹配且数据等于某值时触发），不产生额外停顿；软件条件断点则由调试器在每次命中后求值表达式，若为假则自动继续。后者会显著拖慢执行速度，在中断频繁的代码中尤其明显。

二、断点选择策略

选择断点类型时，可以按以下优先级判断：

• 定位代码执行路径：优先用硬件断点，避免修改 Flash 内容，且命中开销最小。若硬件断点耗尽，再考虑软件断点或 Flash 断点。
• 定位变量被改写：必须用数据断点。先确认变量地址（可在 Ozone 的 Watch 窗口查看），再在 DWT 中配置写观察点。若变量是结构体成员，注意观察点覆盖的地址范围。
• 过滤高频命中：若断点位于循环或中断服务程序中，每次命中都暂停会严重干扰时序。此时应使用条件断点，例如 i == 100 或 state == ERROR，让调试器只在满足条件时暂停。
• 只读 Flash 上的断点：若目标代码在只读 Flash 且硬件断点已用完，Ozone 会提示使用 Flash 断点。此时需确保调试器支持 Flash 断点，并注意其命中延迟高于硬件断点。

三、断点命中后的现场保存

断点命中后，Ozone 会自动暂停 CPU 并读取寄存器组。但“自动读取”不等于“完整保存”。在故障定位场景中，以下信息需要主动记录：

1. 通用寄存器与状态寄存器：R0–R12 保存了函数参数和局部变量，R13（SP）指示当前栈位置，R14（LR）保存返回地址，R15（PC）指向断点处指令。xPSR 中的 IPSR 字段可判断当前是否处于中断上下文。
2. 调用栈回溯：Ozone 的 Call Stack 窗口会根据 LR 和栈内容重建调用链。若栈被破坏，回溯可能失败，此时需要手动检查栈内存。
3. 关键变量快照：在 Watch 窗口中添加与故障相关的变量，命中后立即记录其值。对于数组或缓冲区，可导出内存区域。
4. 外设寄存器状态：若故障涉及外设（如 UART 接收错误、DMA 传输异常），需在 Peripherals 窗口中查看对应外设的状态寄存器。

四、初步分析流程

现场保存完成后，按以下顺序做初步分析：

第一步，看 PC 和调用栈。确认断点是否命中在预期位置。若 PC 指向异常处理程序（如 HardFault_Handler），说明发生了硬件异常，需进一步查看 CFSR、HFSR 等故障状态寄存器。

第二步，看关键变量。对比变量当前值与预期值。例如，一个状态机变量本应为 STATE_IDLE，实际却是 STATE_ERROR，说明状态转换逻辑有问题。

第三步，看中断上下文。检查 xPSR 的 IPSR 字段。若 IPSR 非零，说明当前在中断中，需确认该中断是否应该在此刻触发，以及中断优先级是否配置正确。

第四步，看栈使用情况。检查 SP 是否在合法栈范围内。若 SP 指向非法区域，说明发生了栈溢出，需调整栈大小或检查递归调用。

五、实操示例：定位全局变量被意外改写

假设有一个全局变量 g_sensor_state，在正常运行中应只在传感器任务中修改，但实际出现了异常值。操作步骤如下：

1. 在 Ozone 的 Watch 窗口添加 g_sensor_state，记录其地址（如 0x200001A4）。
2. 打开 Breakpoints 窗口，选择 "New Data Breakpoint"。
3. 地址填入 0x200001A4，访问类型选择 "Write"，大小选择 4 字节。
4. 运行程序，等待命中。
5. 命中后，查看 Call Stack 窗口，确认是哪条指令写入了该地址。
6. 检查该指令所在函数的逻辑，判断是否应该在此处修改 g_sensor_state。

若命中位置在中断服务程序中，而该中断本不应修改此变量，则说明存在中断冲突或共享变量未加保护。此时可进一步用条件断点过滤，例如设置条件为 g_sensor_state != expected_value，只在异常写入时暂停。

通过上述断点体系与现场捕获方法，可以在不破坏目标系统运行状态的前提下，快速定位故障根因。关键在于：根据故障类型选对断点，命中后完整保存现场，并按“PC → 调用栈 → 变量 → 中断上下文 → 栈”的顺序做初步分析。