1. 课程导入与工程视角建立

嵌入式系统一旦进入现场，故障往往不是“程序跑不起来”这么简单，而是偶发死机、HardFault、任务卡死、内存被踩、栈溢出、看门狗复位等难以复现的问题。此时，工程师真正需要的不是“再下载一次程序看看”，而是一套能够冻结现场、还原现场、解释现场的手段。SEGGER Ozone 正是围绕这一需求设计的图形化调试与回溯工具：它通过 J-Link 连接目标芯片，读取调试信息与内存状态，让开发者能够在程序崩溃后仍然看到调用栈、寄存器、变量和反汇编，从而把“现象”转化为“证据”。

理解 Ozone 的价值，首先要区分两个经常被混用的概念：调试与回溯。调试通常发生在开发阶段，目标是主动控制程序执行，例如设置断点、单步执行、观察变量、修改寄存器，属于“向前推进”的过程。回溯则发生在故障之后，目标是从已经停止或已经复位的系统中，反向推断故障发生时的执行路径，属于“向后追问”的过程。Ozone 同时覆盖这两类能力，但本课程更关注后者：当设备已经死机、已经复位、已经进入异常处理程序时，如何利用有限信息还原真相。

上图展示了本课程的基本工程视角：左侧是目标系统，中间是 J-Link 物理通道，右侧是 Ozone 的分析能力。故障发生后，目标系统处于异常状态，J-Link 负责把内存、寄存器和调试信息搬运到 Ozone，Ozone 再通过调用栈、反汇编、变量视图和时间线记录，把零散数据组织成可解释的证据链。最终输出不是“我看到了一个错误”，而是“我能够说明错误发生在哪个函数、哪条指令、哪个变量上，并且能够验证修复是否有效”。

为什么需要专门的回溯工具

很多开发者习惯用串口打印来定位问题，这在简单场景下有效，但在复杂系统中存在明显局限。第一，打印本身会改变时序，可能掩盖竞态条件；第二，崩溃发生后，打印缓冲区可能已经损坏或来不及输出；第三，打印只能提供“点”信息，无法还原完整调用路径。Ozone 的优势在于它直接访问芯片调试单元，不依赖目标程序主动输出，因此能够在系统已经失控的情况下仍然获取关键状态。

以 Cortex-M 的 HardFault 为例，当异常发生时，处理器会自动将 R0-R3、R12、LR、PC、xPSR 压入当前栈帧。如果开发者能够读取栈指针和这些寄存器，就可以还原出异常发生时的 PC 值，再结合反汇编和符号表，定位到具体指令。Ozone 的调用栈窗口正是基于这一机制，结合栈展开信息，逐层还原函数调用关系。对于栈溢出、空指针跳转、非法指令等问题，这种回溯能力往往比反复加打印更高效。

课程目标与实战路线图

本课程的目标不是简单介绍 Ozone 的菜单和按钮，而是建立一套可复用的故障定位方法。具体包括：理解 Ozone 与 J-Link 的协作机制；掌握连接配置、调试文件加载和符号解析；学会在 HardFault、复位、任务卡死等场景下捕获现场；能够阅读调用栈、寄存器和反汇编；能够结合变量与内存数据分析根因；最终形成一份可评审的故障回溯报告。

实战路线图按照“由浅入深、由单点到系统”的方式组织。前期聚焦工具链搭建与基础调试，包括 Ozone 工程创建、ELF 文件加载、断点与单步、变量观察。中期进入异常与回溯专题，重点分析 HardFault、栈溢出、看门狗复位、RTOS 任务异常等典型场景。后期转向工程化能力，包括多核调试、Trace 时间线、脚本自动化、故障报告输出和团队协作规范。每一章都会围绕真实可复现的示例展开，参数和结果会明确标注为教学示例或合理假设，避免把演示数据误认为实测结论。

需要强调的是，Ozone 不是“万能答案生成器”。它提供的是观察能力和分析入口，真正的根因判断仍然依赖开发者对系统架构、内存布局、中断优先级和并发行为的理解。工具解决的是“看不见”的问题，工程判断解决的是“看不懂”的问题。本课程希望帮助读者同时提升这两方面能力：既知道如何用 Ozone 获取证据，也知道如何用工程思维解释证据。