📚 课程目录第3章 Ozone调试器快速上手

3. Ozone调试器快速上手

Ozone 是 SEGGER 为嵌入式固件提供的图形化调试器，它不依赖 IDE，直接通过 J-Link 与目标芯片通信，读取由编译器生成的 ELF 文件中的符号、调试信息与地址映射，从而把机器码还原成可读的函数、变量和源码行。理解 Ozone 的关键在于：它本身不编译代码，只“消费”ELF 与调试信息，因此工程配置的核心就是把正确的 ELF、正确的目标器件和正确的连接方式三者对齐。

一、新建工程：把 ELF、器件与连接方式对齐

启动 Ozone 后选择 Create New Project，向导会依次要求选择目标器件、调试接口与速度、以及要加载的 ELF 文件。器件选择决定了 J-Link 使用的初始化脚本和内存映射，例如调试 STM32F407 时选择 STM32F407VG，接口通常为 SWD，速度可先设为 4000 kHz，稳定后再提高。ELF 文件一般位于工程的构建输出目录，如 build/Debug/firmware.elf。若 ELF 与器件不匹配，Ozone 仍可能连上芯片，但符号地址会错位，表现为断点打不上或变量显示为乱码。

工程保存为 .jdebug 文件，它记录了上述全部设置。团队协作时把 .jdebug 纳入版本管理，可避免每人重复配置。一个典型的最小配置如下：

Project.SetDevice("STM32F407VG");
Project.SetHostIF("USB", "");
Project.SetTargetIF("SWD");
Project.SetTIFSpeed("4000");
Project.AddFile("build/Debug/firmware.elf");
Project.SetOSPlugin("None");

二、下载与复位：让调试会话从确定状态开始

连接成功后，Ozone 提供 Download & Reset，把 ELF 中的代码段写入 Flash 并复位 CPU。若固件已在 Flash 中且未改动，可直接 Reset 后 Run，节省下载时间。需要注意：复位后停在复位向量还是 main，取决于是否勾选 Stop after reset。调试启动阶段建议勾选，便于在 main 入口确认时钟、外设初始化前的状态。

三、断点与观察点：两种不同的暂停机制

断点按代码地址触发，观察点按数据地址触发，这是两者最本质的区别。在 Ozone 中，把光标放到源码行按 F9 即可设置断点；若要监视某个变量何时被改写，则在 Watch 窗口右键该变量，选择 Set Data Watchpoint，并指定触发条件为写、读或读写。

硬件资源是必须考虑的限制。Cortex-M3/M4 通常只有 6 个指令断点和 4 个数据观察点，超出后 Ozone 会提示无法设置。此时应优先保留关键断点，或改用条件断点减少触发次数。例如要定位 adc_value 被异常改写的位置，可设置写观察点，并附加条件 adc_value > 4000，只在越界时暂停，避免频繁中断。

条件断点的表达式直接使用 C 语法，可引用当前作用域内的变量。例如在循环中排查第 100 次迭代的问题：

// 条件断点表达式示例
i == 100 && buffer[i] == 0xFF

四、实时变量监视：区分“实时”与“暂停时”

Ozone 的 Global Data 与 Local Data 窗口在 CPU 暂停时读取内存并解析符号，显示的是暂停瞬间的值。若希望不暂停也能观察变量变化，需要使用 Live Watch（实时监视），它通过 J-Link 周期性读取指定地址，刷新间隔可设为 100 ms 至 1 s。实时监视适合观察计数器、状态机变量、传感器读数等缓慢变化的量；对于高频变化的变量，采样会失真，此时应改用 Timeline 或 Data Sampling 功能记录一段时间的数据。

变量显示异常时，先检查三点：ELF 是否为当前固件版本、编译是否开启 -g、优化等级是否过高。开启 -O2 后，局部变量可能被放入寄存器或直接消除，导致 Ozone 显示 <optimized out>。调试阶段建议使用 -Og 或 -O0，并保留 -g3 以获得完整的宏与类型信息。

五、调用栈查看：从崩溃现场回溯执行路径

当程序停在 HardFault 或断点时，Call Stack 窗口按从内到外的顺序列出函数调用链，每一行对应一个栈帧，包含函数名、源文件与行号。点击任意一帧，Ozone 会同步切换源码视图与局部变量视图，便于逐层检查参数与返回值。

若调用栈显示不完整或出现 ???，常见原因是栈被破坏、优化导致帧指针省略、或中断处理函数未正确标注。可在编译时加入 -fno-omit-frame-pointer，或在 Ozone 中启用 Stack Unwinding 的 DWARF 模式。对于 RTOS 环境，加载对应的 OS 插件（如 FreeRTOS 插件）后，调用栈会按任务维度展示，能直接看到当前运行的是哪个任务、阻塞在哪个信号量上。

调试会话结束后，Ozone 会把断点、观察点和窗口布局保存在 .jdebug 中。下次打开工程即可恢复现场，无需重新设置，这对反复排查同一问题非常高效。

观察点触发会显著降低 CPU 实时性，因为每次数据访问都可能产生调试异常。定位到问题后应及时删除观察点，避免影响固件正常时序，尤其是对时间敏感的通信或控制循环。

把上述流程串起来，一次典型的排查过程是：新建工程并加载 ELF → 下载复位 → 在可疑函数入口设断点 → 运行至断点后查看调用栈与局部变量 → 对异常变量设写观察点 → 触发后检查改写来源 → 修正代码后重新构建并重复验证。掌握这条链路，Ozone 就能从“能连上”变成真正能定位问题的工具。