📚 课程目录第4章自动化调试环境搭建

4. 自动化调试环境搭建

自动化调试环境与手工点按调试最大的区别在于：脚本要能无人值守地启动、连接、复位、读写内存并回收结果。因此环境搭建的目标不是“能打开 TRACE32”，而是让 TRACE32 的安装、目标连接、通道选择和脚本工程形成一个可重复、可版本化、可被 CI 或批处理调用的整体。本节按“软件安装 → 目标连接 → 通道选择 → 工程组织 → 版本管理”的顺序展开，其中前四项决定脚本能否跑通，最后一项决定脚本能否长期维护。

一、TRACE32 安装与配置

TRACE32 采用“主程序 + 架构相关组件 + 硬件驱动”的结构。以 Windows 主机为例，典型安装目录为 C:\T32，其下 bin\windows64 存放可执行文件，demo 存放示例脚本，pdf 存放手册。安装时需注意三点：

架构组件要与目标 CPU 匹配。例如调试 ARM Cortex-M 需要 arm 相关组件，调试 RISC-V 需要 riscv 组件。组件缺失时启动会报 “no debugger for this architecture”。
调试硬件驱动要单独安装。使用 Lauterbach 的 TRACE32 硬件（如 PowerDebug、CombiProbe）需安装对应 USB/以太网驱动；使用第三方探针则需安装其驱动并在配置中声明。
配置文件 config.t32 决定启动行为。它通常位于安装目录或工程目录，内容形如：

; config.t32 示例（节选）
PBI=
USB
; 或使用以太网连接调试硬件
; NET
; NODE=192.168.1.100
; PORT=20000

SCREEN=
HEADLESS

PRINTER=
; 关闭交互界面，适合自动化

其中 PBI（Parallel Bus Interface）段声明主机与调试硬件的物理通道，SCREEN=HEADLESS 让 TRACE32 以无界面方式运行，这是自动化脚本能后台执行的关键。配置完成后可用 t32marm.exe -c config.t32 启动验证，若能看到 TRACE32 提示符并执行 SYStem.CPU 查询，说明主程序与配置基本可用。

二、目标板连接与调试通道选择

目标板连接的核心是“调试通道 + 目标访问方式”的组合。常见通道有三类：

JTAG：引脚多（TCK/TMS/TDI/TDO/TRST），支持多器件菊花链，适合传统 ARM7/9、部分 DSP。
SWD：两线（SWCLK/SWDIO），引脚少、速率高，是 Cortex-M 的主流选择。
cJTAG / 2-pin JTAG：在 JTAG 基础上压缩引脚，常见于部分 SoC。

选择通道时要同时确认目标供电、复位方式和时钟。例如 SWD 连接下，若目标板由调试器供电（SYStem.JtagClock 与 SYStem.Option 相关），需确认电压域一致；若目标板自供电，则要保证 GND 共地。连接脚本通常写成：

; connect.cmm 示例
SYStem.CPU CortexM4
SYStem.JtagClock 10MHz
SYStem.Option ResBreak OFF
SYStem.Option EnReset OFF
SYStem.Mode Attach
; 或 SYStem.Mode Up 用于上电复位后连接

执行后若返回 SYStem.Mode 为 Attach 或 Up，且 SYStem.Up 无报错，说明通道已建立。若报 “debug port not found”，优先检查 SWDIO/SWCLK 是否接反、目标是否处于复位、时钟是否过高。

三、脚本工程目录组织

脚本工程目录应把“环境配置、连接脚本、测试脚本、日志、版本库”分开，避免把 config.t32 与业务脚本混在一起。推荐结构如下：

t32-auto/
├── config/
│   ├── config.t32          ; 主机与硬件通道配置
│   └── target.cmm          ; 目标 CPU、时钟、复位配置
├── scripts/
│   ├── connect.cmm         ; 连接与初始化
│   ├── reset_run.cmm       ; 复位并运行
│   └── read_mem.cmm        ; 内存读取与结果输出
├── tests/
│   ├── test_boot.cmm       ; 启动测试
│   └── test_ram.cmm        ; RAM 读写测试
├── logs/
│   └── 2025-01-01_run.log
└── .gitignore

其中 config/ 存放与硬件相关的配置，scripts/ 存放可复用的原子操作，tests/ 存放具体测试用例，logs/ 存放运行输出。脚本之间通过 DO 命令互相调用，例如 test_boot.cmm 开头写 DO ../scripts/connect.cmm，这样连接逻辑只维护一份。

四、版本管理与可重复性

脚本工程必须纳入 Git 管理，但要注意两点：一是不要把 logs/ 和临时输出提交进仓库，用 .gitignore 排除；二是 config.t32 中若含本机路径或 IP，应使用模板 + 本地覆盖的方式，例如提交 config.t32.template，本地生成 config.t32 并忽略。这样不同机器拉取后只需改少量参数即可运行。

版本管理还应记录“脚本 + 目标固件 + 调试硬件”三者的对应关系。建议在每次运行日志头部写入：

; run_header.cmm
PRINT "=== RUN HEADER ==="
PRINT "DATE: " DATE()
PRINT "SCRIPT_VERSION: v1.2.0"
PRINT "TARGET_FW: 0x08000000"
PRINT "PROBE: PowerDebug USB"
PRINT "==================="