📚 课程目录第2章 TRACE32调试环境搭建

2. TRACE32调试环境搭建

在Cache与MMU故障定位中，调试环境本身是否可靠，直接决定后续观察到的现象是否可信。如果符号加载错位、调试通道带宽不足、多核会话没有正确绑定，那么看到的Cache命中率、页表遍历异常、TLB行为都可能来自错误的上下文。本节围绕TRACE32调试环境的搭建展开，重点说明连接目标芯片、加载符号、配置调试通道以及多核与异构系统下的基本设置。

一、连接目标芯片：先确认物理链路与调试接口

TRACE32与目标芯片的连接通常通过调试探针完成，常见接口包括JTAG、SWD、cJTAG以及面向多核SoC的Aurora、Trace Port等。连接前需要确认三件事：目标板供电与复位状态、调试接口电平与引脚定义、以及芯片是否处于可调试状态。对于带安全启动或TrustZone的芯片，还要确认调试认证是否已通过，否则探针可能只能识别到ID而无法访问内核。

在TRACE32中，连接目标芯片一般通过SYStem.CPU指定内核类型，再通过SYStem.JtagClock设置JTAG时钟。例如：

SYStem.CPU CortexA53
SYStem.JtagClock 10MHz
SYStem.Up

执行SYStem.Up后，TRACE32会尝试复位并停止内核。如果返回错误，应优先检查复位引脚是否被外部拉低、JTAG时钟是否过高、以及芯片是否处于低功耗状态。对于多核芯片，SYStem.Up默认可能只连接第一个内核，后续需要通过SYStem.CONFIG查看可用的核列表。

二、加载符号：让地址与源码建立对应关系

符号加载是Cache与MMU调试的基础。没有符号，看到的只是地址和反汇编；有了符号，才能把异常地址映射到函数、变量和源码行。TRACE32支持ELF、DWARF、PDB等多种符号格式，通常使用Data.LOAD.Elf命令加载。

Data.LOAD.Elf /home/project/build/kernel.elf /NoClear
Data.LOAD.Elf /home/project/build/app.elf /NoClear

加载符号时需要注意三点。第一，符号文件必须与目标上运行的镜像完全一致，包括编译选项、链接脚本和版本号；否则函数地址会偏移，断点可能落在错误位置。第二，对于MMU开启后的虚拟地址空间，符号通常按虚拟地址链接，因此需要在MMU使能后再查看符号，否则地址对不上。第三，对于多核系统，不同核可能运行不同镜像，需要分别加载符号并绑定到对应核。

如果符号加载后断点无法命中，可先用Data.List查看符号表是否包含目标函数，再用Address.OFFSET检查地址偏移是否为0。若偏移不为0，说明符号与镜像不匹配。

三、配置调试通道：JTAG、Trace与实时传输

调试通道决定了TRACE32能看到多少运行时信息。JTAG/SWD用于控制内核、读写寄存器和内存；Trace通道用于捕获指令流和数据流；实时传输通道用于在不停核的情况下输出printf或事件日志。对于Cache与MMU问题，Trace通道尤其重要，因为Cache缺失、TLB miss和页表遍历往往发生在极短时间内，仅靠断点很难捕捉。

配置Trace通道时，需要设置Trace源、Trace时钟和缓冲区大小。例如：

Trace.METHOD Onchip
Trace.CONFIG 0x40000000 0x01000000
Trace.Up

其中0x40000000为Trace缓冲区基地址，0x01000000为大小。配置完成后，可通过Trace.List查看指令流，通过Trace.STATistic查看Cache命中与缺失统计。如果Trace缓冲区溢出，应降低Trace时钟或缩小采集范围，只保留与Cache/MMU相关的地址区间。

四、多核与异构系统的基本设置

多核与异构系统是Cache与MMU故障的高发场景。典型问题包括：核间Cache一致性失效、共享页表被错误修改、TLB shootdown未同步、以及大小核之间地址空间映射不一致。TRACE32通过SYStem.CONFIG和CORE.ASSIGN来管理多核会话。

SYStem.CONFIG CORE 0
SYStem.CONFIG CORE 1
CORE.ASSIGN 0 1
SYStem.Mode Attach

对于异构系统，例如Cortex-A与Cortex-M共存，或DSP与MCU共存，需要为每个核单独指定CPU类型和符号文件。建议为每个核建立独立的窗口布局，把Cache寄存器、MMU页表基址、TLB状态和当前PC放在同一视图内，便于交叉比对。

五、环境搭建后的最小验证

完成连接、符号加载、通道配置和多核绑定后，建议执行一组最小验证，确认环境可用于Cache与MMU调试。验证内容包括：读取当前核的SCTLR寄存器确认MMU与Cache使能位；读取TTBR0/TTBR1确认页表基址；读取TLB状态或使用Trace.STATistic查看Cache命中统计；在多核间切换并确认每个核的符号和寄存器视图正确。

Register.View SCTLR
Register.View TTBR0
Register.View TTBR1
Trace.STATistic
CORE.ASSIGN 0
Register.View SCTLR
CORE.ASSIGN 1
Register.View SCTLR

如果SCTLR的M位为1，说明MMU已使能；C位为1说明D-Cache使能；I位为1说明I-Cache使能。若这些位与预期不符，应先检查启动代码和复位流程，而不是直接怀疑Cache控制器故障。只有在环境确认可靠之后，后续的Cache一致性、TLB miss、页表遍历异常等定位工作才有意义。

多核系统中，不同核的SCTLR、TTBR和TLB状态可能不同。切换核时务必确认当前CORE.ASSIGN指向的目标核，避免把Core 0的页表基址误认为Core 1的配置。

本节搭建的环境是后续所有Cache与MMU故障定位的基准。连接可靠、符号准确、通道充足、多核绑定清晰，才能保证观察到的现象真实反映目标芯片行为，而不是调试环境本身引入的假象。