4. 断点体系与复杂控制流
在 Ozone 中，“断点”并不是一个单一功能，而是一套由调试硬件能力、目标代码属性和调试意图共同决定的机制体系。理解这套体系的关键，是先分清两类底层实现：硬件断点由 Cortex-M 内核的 FPB（Flash Patch and Breakpoint）单元或调试比较器实现，数量有限（典型为 2～8 个），但可以作用于 Flash 中的代码，且不修改目标内存；软件断点由调试器把目标地址处的指令临时替换为断点指令（ARM Thumb 下为 BKPT，编码 0xBE00），数量几乎不受限，但要求该地址位于可写的 RAM 中，且会改变内存内容。Ozone 在设置断点时，会根据地址所在区域自动选择实现方式，并在 Breakpoints & Watchpoints 窗口中用不同图标区分。
实际工程中，复杂控制流往往无法靠“停在某一行”解决。例如一个在中断与主循环之间反复切换的状态机，或一个只在特定输入组合下才越界的数组访问，都需要更精细的断点类型。下面这张图给出了 Ozone 断点体系从“调试意图”到“底层实现”再到“命中行为”的完整映射关系，可作为选择断点类型的决策参考。
在 Ozone 中设置断点的入口很直接：在 Source 窗口左侧行号区单击，或在 Disassembly 窗口对应指令处单击，即可切换断点。右键菜单中的 Set Breakpoint 与 Set Data Breakpoint 分别对应代码断点与数据断点。对于条件断点，可在 Breakpoints & Watchpoints 窗口中选中某条断点，在 Condition 字段填入 C 表达式，例如 g_rxCount > 128 && g_state == 3。Ozone 会在每次命中该地址时求值，只有表达式为真才真正停下；若表达式为假，则自动继续运行。需要特别注意的是，条件表达式应避免调用有副作用的函数，也不要写入变量，否则会改变程序行为。
数据断点（Watchpoint）在排查“谁改了我的变量”这类问题时不可替代。假设有一个全局变量 uint32_t g_sensorRaw;，在正常运行中偶尔被写成异常值。可以在 Watch 窗口右键该变量选择 Set Data Breakpoint，或在 Breakpoints 窗口手动填写地址与访问类型。Ozone 会借助 Cortex-M 的 DWT 比较器监视该地址，当发生写访问时立即停下，此时调用栈通常能直接指向肇事代码。数据断点同样受硬件资源限制，典型芯片提供 4 个 DWT 比较器，因此不要同时监视过多变量；若确实需要观察多个字段，可考虑把它们合并到一个结构体中，用结构体首地址加偏移的方式设置一个范围断点。
断点组解决的是“场景切换”问题。例如调试通信协议时，你可能同时关心 UART 接收中断、DMA 完成中断和协议解析函数三处断点；而在调试控制算法时，又只关心 PID 计算和 PWM 更新两处。与其反复逐条启用禁用，不如在 Breakpoints 窗口中建立两个组，分别命名为 Comm 和 Control，把断点拖入对应组，之后通过组级别的复选框一键启停。Ozone 还支持在断点组上设置统一的命中动作，例如命中后执行一段命令脚本，用于打印关键变量或记录时间戳。
多核断点管理是复杂 SoC 调试中的难点。以双核 Cortex-M 系统为例，两个核可能共享同一段 Flash 代码，但各自有独立的 FPB 与 DWT 资源。Ozone 在连接多核目标时，会在 Breakpoints 窗口为每条断点标注所属核。若一条断点被错误地绑定到不执行该代码的核上，就会出现“断点永远不命中”的现象。正确做法是：先确认代码映射关系，再在断点属性中显式指定核；对于核间共享的同步点，可以在两个核上分别设置断点，并配合 Break All 或核间同步停止选项，使一个核停下时另一个核也进入暂停，便于观察共享内存与信号量状态。
最后给出一个可参考的断点配置示例，用于调试一个带 DMA 的串口接收状态机。假设接收缓冲区为 uint8_t g_rxBuf[256];，状态变量为 volatile uint8_t g_rxState;，DMA 完成中断服务函数为 DMA1_Channel5_IRQHandler。可以这样组织：
Breakpoint 1: DMA1_Channel5_IRQHandler // 硬件断点，观察中断入口
Breakpoint 2: g_rxState == 2 // 条件断点，仅在解析状态停下
Watchpoint 1: &g_rxBuf[0], Write // 数据断点，捕获缓冲区首字节被改写
Group "RX": { Breakpoint 1, Breakpoint 2, Watchpoint 1 }
运行后，若 Watchpoint 1 先命中，说明在 DMA 完成前就有代码写入了缓冲区，应检查是否有其他任务误用了该数组；若 Breakpoint 2 命中时 g_rxBuf 内容与预期不符，则可结合 Call Stack 与 Memory 窗口确认数据来源。通过这种“代码断点定位流程、条件断点缩小范围、数据断点锁定写入者、断点组管理场景”的组合方式，才能在复杂控制流中把问题收敛到可验证的最小范围。