1. 课程导入与调试环境总览
在 SoC（System on Chip）开发中，硬件团队关心的是时序、功耗与信号完整性，软件团队关心的是驱动、协议栈与任务调度，而真正让二者"对上话"的，是调试系统。TRACE32（Lauterbach 出品的调试工具套件）正是这样一套横跨软硬件边界的调试基础设施：它既能通过 JTAG/SWD 等物理接口直接访问 CPU 内核、内存与外设寄存器，又能借助片上调试模块（如 ARM CoreSight、RISC-V Debug Module）实现非侵入式跟踪，从而把"硬件上电后到底发生了什么"变成可观测、可复现、可定位的数据。
理解 TRACE32 的定位，关键是理解它处在 SoC 调试链路的哪一环。一颗典型 SoC 的调试通路可以抽象为：调试主机（PC 上的 TRACE32 软件）→ 调试探针（如 Lauterbach 的 PowerDebug / µTrace 硬件）→ 目标板调试接口（JTAG/SWD/cJTAG）→ 片上调试组件（DAP、APB-AP、AHB-AP、ETM/ETB、STM 等）→ CPU 内核与总线矩阵。TRACE32 的软件层负责把用户操作翻译成调试协议报文，探针负责电气与时序转换，片上组件负责执行"读寄存器""设断点""抓跟踪"等动作。这条链路上任何一环配置错误，都会表现为"连不上""断点不生效""跟踪无数据"等典型故障。
从工具链组成看，TRACE32 并不是单一软件，而是一组协同工作的组件。核心是 TRACE32 调试器主程序（如 t32marm.exe 对应 ARM 架构），它负责解析用户命令、管理调试会话、呈现寄存器与内存视图。与之配合的是架构描述文件（.cmm 脚本、.per 外设描述文件）和符号文件（ELF/DWARF），前者告诉调试器"这颗 SoC 的寄存器在哪个地址、位域如何定义"，后者告诉调试器"变量名对应哪个地址、源码行对应哪条指令"。探针固件则负责把主机下发的调试请求转换为 JTAG/SWD 时序。此外，跟踪解析工具（如 Trace Decoder）用于把 ETM/STM 输出的压缩跟踪数据还原为可读的指令流与时间戳。
实验平台搭建是本节最需要动手的部分。以一颗典型的 ARM Cortex-A 应用处理器 SoC 为例，推荐的最小实验环境包括：一块带 JTAG 排针或 SWD 接口的开发板、一台安装 TRACE32 的 PC、一根 Lauterbach 探针（如 µTrace 或 PowerDebug + 相应调试电缆）、以及目标板的电源与串口线。连接顺序建议为：先接好探针与目标板的调试接口，再给目标板上电，最后启动 TRACE32 软件。若顺序颠倒，可能出现探针无法识别目标或 IDCODE 读取失败。
启动 TRACE32 后，第一步是建立调试会话。在 SYStem 菜单下选择 Configure，指定探针类型与目标接口（JTAG 或 SWD），然后执行 SYStem.Up 命令。若连接正常，TRACE32 状态栏会显示目标电压、IDCODE 和识别到的内核类型。例如，某 Cortex-A53 目标可能返回 IDCODE 0x4BA00477，并识别出 4 个 A53 核。此时可用 SYStem.CPU 确认内核型号，用 SYStem.JtagClock 调整 JTAG 时钟频率——频率过高会导致长排线场景下时序余量不足，典型做法是从 1 MHz 起步，稳定后再逐步提升。
接下来是加载符号与源码。通过 Data.Load.ELF 命令加载编译生成的 ELF 文件，TRACE32 会自动读取 DWARF 调试信息，建立"源码行—指令地址—变量地址"的映射。此时打开 List 窗口即可看到源码与反汇编的混合视图。若符号加载失败，常见原因是 ELF 未带 -g 编译选项，或链接地址与目标实际运行地址不一致。对于裸机程序，链接地址通常就是加载地址；对于 Linux 内核模块，则需要额外处理 KASLR 偏移。
断点设置是软硬件协同调试的典型交叉点。TRACE32 支持硬件断点和软件断点两类：硬件断点由 CPU 的断点单元实现，数量有限（通常 4~8 个），但可作用于 ROM 和只读区域；软件断点通过替换指令实现，数量几乎不受限，但要求目标内存可写。在 Breakpoint 窗口中设置断点后，可用 Breakpoint.List 查看当前断点类型与地址。若断点未命中，应检查：断点地址是否落在实际执行路径上、该地址是否被 MMU 映射、以及是否被其他调试器或安全策略屏蔽。
当需要观察"程序为什么跑飞"或"中断响应延迟多少"这类问题时，单步与断点往往不够，此时需要启用跟踪。以 ETM 指令跟踪为例，配置流程大致为：在 Trace 菜单下选择 Configure，指定跟踪源（ETM）、跟踪缓冲（ETB 或外部 Trace Port）、以及跟踪数据格式；然后执行 Trace.ON 开始采集，运行程序后执行 Trace.OFF 停止，再用 Trace.List 或 Trace.Chart 查看指令流。跟踪数据能还原出分支跳转、函数调用与返回、以及精确的指令执行序列，是定位偶发性时序问题的关键手段。
最后需要建立的一个认知是：TRACE32 的调试能力受限于 SoC 的调试架构设计。如果芯片在流片时未引出足够的调试引脚、未集成 ETB、或对 DAP 做了安全锁定，那么再强大的调试器也无法获取对应信息。因此，软硬件协同调试不仅是软件工程师使用工具的问题，也是硬件工程师在 SoC 设计阶段就需要预留调试资源的问题。理解这条链路上的每一环，才能在遇到"连不上、断不住、跟不到"时快速定位是工具配置、目标板硬件还是芯片设计层面的原因。