4. TRACE32启动脚本与初始化命令

TRACE32 的调试能力并非在连接目标芯片的瞬间就自动就绪。调试器上电后，CPU 处于复位或未知状态，MMU 未建立页表，Cache 内容不可信，内存控制器可能尚未初始化，此时若直接读取内存或设置断点，得到的往往是错误结果甚至总线异常。启动脚本（通常以 .cmm 为扩展名）正是解决这一问题的核心手段：它把 SYStem、CPU、MMU、Cache 等初始化命令按正确顺序组织起来，使调试器从"裸机"状态进入可控、可观测的调试环境。

4.1 启动脚本的执行模型与命令分类

TRACE32 的脚本由 PRACTICE 语言解释执行，命令按行顺序生效，前一条命令的结果会直接影响后一条命令能否成功。因此理解命令之间的依赖关系，比记住命令本身更重要。初始化命令大致可分为四类：

  • 系统级命令（SYStem）：定义调试器与目标系统的连接方式，如 SYStem.CPU 选择内核类型、SYStem.JtagClock 设置 JTAG 时钟、SYStem.Option 配置复位行为、SYStem.Up 建立物理连接。
  • 内核级命令（CPU）：设置内核运行模式、异常向量基址、栈指针等，如 CPU.ARM 系列命令、CPU.CONFIG 等。
  • 存储管理命令（MMU）：建立地址转换视图，如 MMU.ON、MMU.TableBase、MMU.Dump，使调试器能按虚拟地址访问内存。
  • 缓存命令（Cache）：控制 Cache 的可见性与一致性，如 Cache.ON、Cache.Flush、Cache.Dump，避免读到过期的缓存行。

这四类命令存在明确的依赖链：SYStem 建立物理连接是前提，CPU 配置决定内核行为，MMU 和 Cache 则影响内存访问的正确性。下图展示了这一依赖关系与典型执行顺序。

TRACE32 启动脚本初始化依赖链 ① SYStem 层 — 建立物理连接 SYStem.CPU CortexA53 · SYStem.JtagClock 10MHz · SYStem.Option RESet · SYStem.Up 作用：选择内核、设定 JTAG 速率、决定是否复位目标、建立调试通道 ② CPU 层 — 配置内核运行环境 CPU.ARM · CPU.CONFIG · CPU.SetReg SP,0xFFFF0000 · CPU.SetReg PC,0x80000000 作用：设定内核模式、异常向量、栈指针与入口地址 ③ MMU 层 — 地址转换视图 MMU.TableBase 0x40000000 MMU.ON · MMU.Dump ④ Cache 层 — 一致性控制 Cache.ON · Cache.Flush Cache.Dump · Cache.OFF 调试环境就绪：可正确读写内存、设置断点、观察变量 若任一环节缺失或顺序错误 → 总线异常 / 读到脏数据 / 断点失效

4.2 启动脚本编写规范

脚本的可靠性取决于几个容易被忽视的细节。首先是错误处理：PRACTICE 默认在命令失败时继续执行，这会导致后续命令在错误状态下运行。建议在关键命令后使用 IF ERROR() 判断并终止，或使用 ON ERROR 定义统一处理入口。其次是参数化：把 CPU 类型、时钟频率、内存基址等定义为变量，便于在不同板卡间复用。

; 示例：带错误处理的启动脚本片段
LOCAL &cpuType &jtagClk &memBase
&cpuType = "CortexA53"
&jtagClk = 10000000
&memBase = 0x40000000

SYStem.CPU &cpuType
SYStem.JtagClock &jtagClk
SYStem.Option RESet
SYStem.Up
IF ERROR()
(
    PRINT "SYStem.Up 失败，检查 JTAG 连接与供电"
    ENDDO
)

MMU.TableBase &memBase
MMU.ON
Cache.Flush

第三是可重复性：脚本应能在目标复位后重复执行而不残留状态。这意味着在脚本开头显式关闭 MMU 和 Cache，或使用 SYStem.Option RESet 强制复位，避免上一次调试留下的页表或缓存状态干扰本次初始化。

4.3 复杂 SoC 的定制化初始化实践

复杂 SoC 通常包含多个异构核（如 A 核 + R 核 + DSP）、多级 Cache、以及分散在不同电源域的内存控制器。此时"一刀切"的脚本无法工作，需要按核、按域定制。

以一颗典型的车载 SoC 为例：A53 应用核运行 Linux，R5 实时核运行 AUTOSAR，两者共享 DDR 但各自有独立的 MMU 配置。调试 A53 时，需要先通过 SYStem.CPU CortexA53 选择核，再加载 Linux 的页表基址；调试 R5 时则切换为 SYStem.CPU CortexR5，并使用 R5 的 MPU 配置。若两个核同时调试，需使用 SYStem.MultiCore 或 CORE.ASSIGN 建立多核会话。

另一个常见问题是内存控制器未初始化。在 SoC 上电初期，DDR 控制器可能仍处于复位状态，此时访问 DDR 地址会返回总线错误。解决方案是在脚本中先通过 SYStem.Up 连接，然后使用 Data.Set 或 PER 命令直接写 DDR 控制器的配置寄存器，完成初始化后再访问 DDR。这一过程需要参考 SoC 手册中的寄存器地址与位定义，不能凭经验猜测。

实践提示：对于多核 SoC，建议为每个核编写独立的初始化脚本，再用一个顶层脚本按调试需求调用。这样既避免了单脚本过于臃肿，也便于在某个核的初始化失败时快速定位。
注意：MMU.ON 之后，调试器看到的地址空间会从物理地址切换为虚拟地址。如果脚本中混用了物理地址和虚拟地址，会出现"同一变量两次读取值不同"的现象。建议在脚本中用注释明确标注当前处于哪个地址视图。

最后，启动脚本的验证不能只看"是否执行完毕"，而应检查关键状态：用 SYStem.State 确认连接状态，用 MMU.Dump 确认页表已生效，用 Cache.Dump 确认缓存行为符合预期。只有这些状态都正确，后续的断点设置、变量观察和故障定位才有可靠基础。

← 上一章 📖 返回目录 下一章 →