2. TRACE32核心调试概念与实时系统基础

在嵌入式实时系统中，调试的难点往往不在于“程序能不能跑”，而在于“任务是否按预期被调度、中断是否及时响应、优先级是否被反转、上下文切换是否带来额外开销”。TRACE32 作为硬件辅助调试工具，能够在不破坏系统实时性的前提下观察这些行为。理解实时系统的运行机制，是正确使用 TRACE32 各项功能的前提。

一、实时系统的任务调度与优先级

实时系统通常由 RTOS 管理多个任务，每个任务拥有独立的任务控制块（TCB）、栈空间和优先级。调度器依据优先级决定当前哪个任务占用 CPU。以常见的抢占式调度为例，优先级数值越小（或越大，取决于 RTOS 约定）代表优先级越高。当高优先级任务就绪时，会立即抢占正在运行的低优先级任务。

假设系统中有三个任务：

在 1 ms 周期内，MotorCtrl 必须完成一次控制计算。若 CommTask 正在执行且未主动让出 CPU，MotorCtrl 就绪后会立即抢占。这种抢占行为是否发生、发生时刻是否准确，正是 TRACE32 需要观测的核心内容。

二、中断与上下文切换

中断是实时系统响应外部事件的机制。中断服务程序（ISR）通常具有比任何任务都高的执行优先级。中断发生时，CPU 保存当前任务的上下文（程序计数器、状态寄存器、通用寄存器等），跳转到 ISR 执行，执行完毕后恢复上下文并返回被中断的任务。这一保存与恢复过程就是上下文切换。

上下文切换本身有开销。以 Cortex-M 为例，硬件自动压栈 8 个寄存器，若 ISR 中调用函数或使用浮点单元，还需软件额外保存。假设每次切换约 1～2 μs，若系统每秒发生 10000 次切换，则仅切换开销就占 1%～2% 的 CPU 时间。TRACE32 可以通过跟踪单元记录切换事件，帮助判断切换频率是否合理。

三、TRACE32 符号加载与调试会话

TRACE32 要正确显示任务名、函数名和变量名，必须加载与目标程序匹配的符号文件（通常是 ELF 或 AXF 格式）。符号加载通过 Data.LOAD.Elf 命令完成：

Data.LOAD.Elf motor_ctrl.elf /NoClear

其中 /NoClear 表示加载符号时不擦除已有断点。若符号文件与目标程序版本不一致，会出现函数名错位、变量地址错误等问题。加载后可用 sYmbol.List 查看符号表，确认关键任务函数是否存在。

调试会话（Debug Session）是 TRACE32 与目标芯片建立连接后的工作环境。一个会话包含目标配置、符号信息、断点、窗口布局等状态。对于多核系统，可以建立多个会话分别调试不同核。会话配置通常保存在 .cmm 脚本中，便于重复使用。

四、窗口布局与核心观测窗口

TRACE32 提供多种窗口用于观察实时系统状态。常用的包括：

• Task Window：显示 RTOS 任务列表、状态、优先级和栈使用情况。
• Stack Frame Window：显示当前任务的调用栈。
• Trace Window：显示指令或任务级跟踪记录。
• Perf Window：统计函数执行时间和调用次数。
• Var Window：观察全局变量或任务控制块字段。

合理的窗口布局应把任务状态、调用栈和跟踪窗口放在同一视野内，便于在任务切换时快速关联。例如，当 Trace Window 显示 MotorCtrl 被唤醒后，可立即在 Task Window 中确认其状态是否变为 ready，再在 Stack Frame Window 中查看其调用路径。

五、从观测到判断：一个典型分析场景

假设在 TRACE32 的 Trace Window 中发现 MotorCtrl 的实际执行周期偶尔从 1 ms 变为 1.5 ms。结合 Task Window 可以看到，在延迟发生的时刻，CommTask 正处于运行状态且未发生抢占。进一步检查中断状态，发现此时有一个低优先级中断正在执行，而该中断的 ISR 中关闭了全局中断。这就解释了延迟原因：中断关闭期间，调度器无法响应 MotorCtrl 的唤醒请求。

这个分析过程体现了 TRACE32 的核心价值：把任务状态、中断状态和上下文切换记录放在同一时间轴上对照，从而定位实时性问题的根因。实际操作中，可以先用 Trace.List 查看跟踪记录，再用 Task.List 确认任务状态，最后用 Var.View 检查中断控制寄存器。

掌握任务调度、中断、优先级和上下文切换的基本机制，并熟悉 TRACE32 的符号加载、调试会话和窗口布局，是后续进行实时性能分析和任务诊断的基础。只有在正确加载符号、建立稳定会话的前提下，各观测窗口的数据才具有可信度。