4. 多核异构 SoC 的调试接入

多核异构 SoC 的调试接入，本质上不是“把多个核分别连上调试器”这么简单。它要解决的是：TRACE32 如何在一个调试会话中同时识别不同架构的核、如何让它们在同一时间基准下启停、如何把核间通信与事件纳入同一观察窗口，以及当某个核“消失”时如何判断是复位、时钟、电源还是调试通路的问题。本节围绕这四个问题展开，并以一个典型的“Cortex-A53 ×4 + Cortex-M4 + C66x DSP + RISC-V E902”异构 SoC 为例说明配置过程。

一、核的发现：从调试拓扑到可寻址核列表

TRACE32 发现核的顺序，取决于 SoC 的调试拓扑。常见结构有三类：JTAG 菊花链（多个 TAP 串联，IR/DR 逐级移位）、多 TAP 并行（每个核或核簇独立 TAP，通过 DAP 选择）、以及CoreSight 单 DAP 多 AP（一个 DAP 下挂多个 Access Port，每个 AP 对应一个核或核簇）。异构 SoC 通常是第三种：ARM 核挂在 AXI-AP 或 APB-AP 上，DSP 与 RISC-V 可能通过自研 DAP 或桥接 AP 接入。

接入前先确认三件事：调试时钟 TCK 是否在目标复位后仍存在；各核的 DBGEN/NIDEN（ARM）或 debug_en（RISC-V）是否被安全策略拉低；DSP 的 EMU0/EMU1 或 TRST 是否被正确释放。若这些信号被 SoC 的 Secure Boot 关闭，TRACE32 会表现为“扫描到 TAP 但读不到 IDCODE”或“IDCODE 全 0/全 F”。

在 TRACE32 中，核发现通常分两步：先用 SYStem.CONFIG 描述拓扑，再用 SYStem.DETECT 或 SYStem.Up 触发实际扫描。例如：

SYStem.CONFIG DEBUGPORT.TYPE APB
SYStem.CONFIG APBAP 0. 0x80000000
SYStem.CONFIG CORE.ASSIGN 1. 2. 3. 4.
SYStem.CONFIG SLAVE 1. A53
SYStem.CONFIG SLAVE 2. M4
SYStem.CONFIG SLAVE 3. C66x
SYStem.CONFIG SLAVE 4. RISCV
SYStem.DETECT

执行后，TRACE32 会在 SYStem 窗口列出每个核的 IDCODE、架构类型、当前状态（Running/Halt/Reset）以及可访问的调试寄存器。若某个核显示为 unknown，优先检查该核的 AP 地址是否与 SoC 手册一致，而不是反复重启调试器。

异构 SoC 调试接入拓扑与核发现路径 TRACE32 主机 SYStem.CONFIG SYStem.DETECT 调试探针 JTAG / SWD TCK 10 MHz CoreSight DAP APB-AP / AXI-AP ROM Table Cortex-A53 ×4 AP: 0x8000_0000 SMP 核簇 CTI/CTM 同步 Cortex-M4 AP: 0x8001_0000 实时控制核 DWT/ITM 事件 C66x DSP AP: 0x8002_0000 EMU0/EMU1 Trace 总线 RISC-V E902 AP: 0x8003_0000 DM + Trigger halt/resume CTI / CTM 交叉触发矩阵 —— 同步启停与核间事件分发 核发现顺序：DAP 扫描 → ROM Table 解析 → AP 枚举 → 核 IDCODE 匹配 → 状态读取

二、同步启停：CTI/CTM 与 TRACE32 的 SMP 配置

同步启停的目标是让多个核在同一个调试事件下同时停止或同时运行。ARM 核簇内部通常通过 CTI（Cross Trigger Interface）与 CTM（Cross Trigger Matrix）互联，DSP 与 RISC-V 则通过各自的触发输入/输出接入 CTM。TRACE32 侧的关键配置是 SYStem.CONFIG CORE.ASSIGN 与 SYStem.Mode 的组合。

以四核 A53 为例，若希望它们作为 SMP 组同步启停，配置如下：

SYStem.CONFIG CORE.ASSIGN 1. 2. 3. 4.
SYStem.CONFIG SMP ON
SYStem.Mode Attach
SYStem.Up

此时在 SYStem 窗口点击 Halt，四个 A53 会同时停止；点击 Go，它们同时运行。对于 M4、DSP、RISC-V，若希望它们也参与同步，需要把它们的 CTI 输出连到 CTM 的同一触发通道，并在 TRACE32 中为每个核单独建立 SYStem.CONFIG SLAVE 条目，再通过 SYStem.CONFIG CORE.ASSIGN 把它们纳入同一个 SYStem 会话。

实际调试中常见的“同步失败”有三种表现：一是某个核不响应 Halt，通常是该核的 CTI 未使能或 DBGEN 被拉低；二是 Halt 后某个核仍在跑，通常是该核被配置为 SYStem.Mode Go 而非 Attach；三是 Halt 后无法恢复，通常是 CTM 触发通道被其他调试会话占用。排查时先用 SYStem.CONFIG 查看各核的 CTI 状态，再检查 SoC 的 CTIEN 寄存器。

三、核间事件：从 ITM/DWT 到 CTM 触发

核间事件是异构调试中最容易“看不见”的部分。Cortex-M4 的 DWT 可以产生数据观察点事件，ITM 可以输出软件跟踪；Cortex-A53 的 ETM 可以输出指令跟踪；DSP 的 EMU 事件可以触发断点；RISC-V 的 Trigger 模块可以产生硬件断点与观察点。这些事件要进入同一个观察窗口，必须通过 CTM 汇聚到 TRACE32 的 Trace 或 Trigger 视图。

一个典型的核间事件配置是：M4 在某个变量写入时触发 DWT 观察点，该事件通过 CTI 输出到 CTM，CTM 再触发 A53 的 CTI 输入，使 A53 在指定地址停止。TRACE32 中对应的配置片段如下：

; M4 侧：DWT 观察点触发 CTI 输出
Break.Set /DWT 0x20001000 /Write
CTI.Out 0. 1.

; A53 侧：CTI 输入触发 Halt
CTI.In 1. Halt

; 全局：使能 CTM 通道 1
CTM.Enable 1.

配置完成后，在 Trace 窗口中可以看到 M4 的 DWT 事件与 A53 的 Halt 事件按时间顺序排列。若事件未出现，先确认 CTM.Enable 是否执行，再确认 M4 的 DWT 是否已使能 CYCCNT 与 POSTCNT。

四、TRACE32 多核配置的工程化建议

多核配置最容易出问题的地方，是把“核发现”和“核同步”混在一起做。建议按以下顺序推进：先单独连接每个核，确认 IDCODE 与状态可读；再配置 CTI/CTM，确认同步启停可用；最后配置核间事件与 Trace。每一步都用 SYStem.CONFIG 保存为独立的 .cmm 脚本，便于复现与排障。

对于异构 SoC，还需要注意地址映射差异：A53 看到的 0x8000_0000 与 DSP 看到的同一物理地址可能不同，TRACE32 的 Data.Load 与 Break.Set 必须使用各核自己的地址视图。若在 A53 上设置的断点在 DSP 上不生效，先检查 SYStem.CONFIG 中的 MMU 与 Address 设置，而不是怀疑断点硬件。

排障提示：当某个核在 SYStem.DETECT 后显示为 unknown，优先检查该核的 AP 地址、DBGEN 电平与调试时钟；当同步 Halt 失败时，优先检查 CTI 使能与 CTM 通道；当核间事件丢失时，优先检查 DWT/ITM/ETM 的使能位与 CTM 通道映射。这三类问题的排查顺序，比反复重启调试器更有效。

最后，多核异构调试的接入质量，最终体现在“能否在一个会话中同时看到所有核的状态、事件与数据”。TRACE32 的 SYStem、Trace、Trigger 三个窗口，分别对应核发现、核间事件与同步控制。把这三者配置到位，后续的核间同步调试、共享内存竞争分析、实时性验证才有可靠的基础。

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