企业官网建设流程全解析

简介：《Trace 劳特巴赫 多核系统调试方法详解》是一份聚焦SMP、AMP与iAMP三种多核调试模式的中文技术资料，面向嵌入式软件开发、硬件调试工程师及具备一定基础的中级读者，用于理解多核处理器在TRACE32环境下的调试配置、核分配管理、同步控制和问题排查。资料共1个PDF文件，压缩包约18.97MB，内容围绕启动配置、核的分配与管理、常用命令、符号表差异及实际芯片案例展开，涉及NXP S32G274A、英飞凌TC275TF、big.LITTLE等典型平台。读者可从中获得SMP、AMP与iAMP的概念对比，掌握Core.assign、Core.number等命令的使用要点，了解多核显示、核状态查看与切换方法，并熟悉不同架构下的调试流程和最佳实践。已有352人学习，适合需要在项目中提升多核调试效率、快速建立调试思路并解决实际问题的工程师参考，尤其适用于多核启动、核间同步、子系统划分及AMP独立调试等场景。

1. 从一颗 SoC 上跑三套软件说起：劳特巴赫多核调试到底在解什么问题

一块域控板卡上，四核 Cortex-A 跑 Linux，一颗 Cortex-R 跑安全岛 RTOS，还有一颗 Cortex-M 管外设时序。板子上只有一条 JTAG 链路引出来。系统偶发卡死时，你既想看 A 核的调度器状态，又想知道 R 核的锁步有没有走偏，还想抓 M 核那条异常中断的来龙去脉。这不是"接个调试器"能解决的问题，而是"一个调试访问端口怎么同时服务三套互不相干的软件栈"。

劳特巴赫 TRACE32 在这类场景里的角色，更像一个多核会话管理器：它把每一个可调试实体建模成一个 CORE，再按核之间的软件关系和硬件路径关系，决定它们是共享一套上下文还是各持一套。SMP、AMP、iAMP 这三组词，描述的就是这份建模关系的三种形态，选错了，症状不是连不上，而是断点飘核、符号串台、trace 时间戳对不齐——排查起来比连不上更费时间。这篇内容面向 SoC 底层软件、BSP 驱动、安全核验证这几类工程师。

2. SMP、AMP、iAMP 的判定标准与 TRACE32 建模选型

2.1 三种模型在运行时的真实差别

SMP 的特征是"一套软件、多份执行"。多个同构核共享同一个 OS 实例、同一份物理内存映射、同一套页表。Linux SMP、Zephyr 的 SMP 配置、FreeRTOS 的多核端口都属于这一类。它对调试提出的核心诉求是：我设的断点应该"哪里执行到都拦"，因为我根本不关心某个函数最终跑在哪颗核上。

AMP 的特征是"多套软件、各管各的"。A 核跑 Linux，R 核跑 RTOS，两者的链接脚本、向量表、启动入口完全不同，甚至指令集都不同。这种情况下，调试 A 核时绝不能把 R 核一起停住——R 核可能正在跑安全监控或者电机换相，停几毫秒就是事故。

iAMP 容易被误解成"AMP 的子集"，其实它描述的是硬件路径而不是软件模型。同一个 SoC 内部的多个核，共享同一个调试访问端口（典型是共享一个 DAP，挂在不同的 AP 上），但每一核的软件栈相互独立。它和跨芯片 AMP 的真正区别在于：跨芯片时你有两条物理链路，可以真正并行操作；iAMP 只有一条链路，所有核的调试动作都在这一条链路上排队，切换核就是切换链路的事务目标。

2.2 TRACE32 侧的三个建模对象

TRACE32 里最基础的概念叫 CORE。SYStem.CONFIG.CORE <n>.是一条作用域切换命令，它本身不产生动作，只是声明"接下来的配置语句归属于第 n 个核"。这一点决定了 .cmm 脚本的写法：多核启动脚本不是一条自上而下的配置流，而是一串按核分块的配置段落。很多人第一次写多核脚本踩的坑，就是忘了在某一段开头写作用域，结果后一段配置全部覆盖到前一个核上。

顺着这个作用域，还要理解主从关系。SYStem.CONFIG.Slave ON|OFF决定该核是主动去建立调试链路，还是被动跟随别的核已经建立的链路。SMP 场景下通常只需要一个 master，其余全部 slave，否则多个核会争抢同一个访问端口，现象是 attach 阶段随机超时，重试几次又能连上，非常难定位。

第三个对象是访问端口本身。AMP 跨器件时，每个器件对应独立的调试器物理接口，config.t32 里会体现为不同的 PBI 配置；iAMP 共享一个 DAP 时，靠 AP 编号和核索引加以区分。所以在写脚本之前，先确认目标板到底有几条物理链路，这个判断错了，后面所有命令都是在错误的树上配置。

2.3 探测先行：配置之前先看调试器认到了什么

不要凭数据手册猜核数。连上之后先执行两条探测命令，让调试器把它实际看到的东西打印出来：

; 探路脚本，不改变任何目标状态 SYStem.CONFIG ; 不带参数时会列出当前 SYStem 树下的可用配置项 CORE.ASSIGN ; 打印核分配表：已连接哪些核、各自归属哪个组

SYStem.CONFIG的价值在于版本差异。不同 TRACE32 版本、不同芯片的 SYStem 子树并不完全一致，与其照抄别人的脚本报错，不如让调试器把可用项列出来，按提示补全。CORE.ASSIGN则回答另一个问题：板子上明明有四核，为什么只认到两个——常见原因是另外两颗核的时钟被门控了，或者复位还没释放。

2.4 三模型对照与判定流程

落到判定上，按顺序问三个问题就够了：第一，多个核是否运行同一个 OS 映像，是则偏向 SMP；第二，各核能否独立复位、独立停止，不能则说明存在耦合，必须按 iAMP 的思路分核控制；第三，调试访问端口是一个还是多个，只有一个就要提前规划分时复用的顺序。

3. SMP 调试流程：一套符号带宽多个核的最小可行配置

3.1 把连接配置和会话配置拆开放

config.t32 负责"调试器怎么接到主机"，.cmm 脚本负责"连上目标以后怎么建立会话"。多核项目里把两者混在一起写，换一块板子就要改两处，是维护成本的主要来源。

OS= ID=SoCDebug SYS=2000 PBI=USB USB=USB0 PRINTER=WINDOWS SCREEN= FONT=SMALL

PBI指定调试器与 TRACE32 软件之间的物理接口类型，USB0是设备实例号，接多个调试器时需要区分。SYS=2000是本地通信端口，同一台主机跑多份 TRACE32 实例时必须错开。这几个参数与目标有几个核完全无关，SMP 和 AMP 通用，所以它们应该待在 config.t32 里而不是脚本里。

3.2 四核同构 SMP 的最小启动脚本

; smp_up.cmm —— 四核同构 Cortex-A，运行同一个 Linux 映像 SYStem.CPU CortexA53 ; 同构核只声明一次 CPU 类型 SYStem.CONFIG.DEBUGPORTTYPE DAP ; 走 CoreSight DAP SYStem.CONFIG.CORE 0. ; 作用域：以下配置只作用于 core0 SYStem.CONFIG.Slave OFF ; core0 作为 master，负责建立访问链路 SYStem.CONFIG.CORE 1. ; 切到 core1 SYStem.CONFIG.Slave ON ; 从核跟随主核，不自己抢链路 SYStem.CONFIG.CORE 2. SYStem.CONFIG.Slave ON SYStem.CONFIG.CORE 3. SYStem.CONFIG.Slave ON SYStem.Mode Attach ; 不断电挂载，保留现场 CORE.ASSIGN ; 确认四核都被识别 Data.LOAD.Elf vmlinux /NoClear ; 四个核共享同一份符号 TASK.ACTIVATE Linux ; 打开 Linux 任务感知

这段脚本的逻辑主线是"先定作用域，再定主从，最后一次性挂载"。SYStem.CONFIG.CORE n.后面的点号不能省，它是作用域的结束标记，漏掉会导致后续语句归属错误。Slave ON在 SMP 场景几乎是标配，因为四个核跑的是同一套代码，让它们各自去竞争同一条调试访问链路没有任何收益，只会让 attach 阶段的成功率下降。

SYStem.Mode Attach和SYStem.Mode Up的区别值得单独记住：Attach 不对目标做复位，直接挂到当前运行状态，适合调试已经在跑的系统；Up 会走一遍复位序列。在 SMP 组里这两条命令都作用于整组，不存在"只复位 CPU1"的用法。

符号加载放在 Attach 之后，是因为 Linux 的 vmlinux 是位置相关的，地址翻译依赖当前 MMU 状态。如果先加载符号再挂载，碰上系统正在切换页表的窗口期，符号地址会偏移一截，后面设断点全部落空。

3.3 组断点的行为与单步的锁依赖问题

SMP 组里最需要提前建立心理预期的是断点语义。Break.Set <addr>默认是组断点，任意一颗核执行到该地址都会触发，并且触发后组内其他核一起停下。这正是 SMP 调试的价值所在——你不需要关心代码最终跑在哪颗核上。但它同时是最大的坑：你以为在调 CPU0 的驱动代码，实际命中它的可能是 CPU2，因为调度器把那个线程迁过去了。

判断当前命中的是哪颗核，最直接的办法是看状态栏的 active core，或者先跑一次CORE.ASSIGN记住核列表。要进一步确认线程位置，用TASK.List看该线程当前挂在哪个核上，必要时临时把线程的 affinity 钉住，让它在调试期间不迁移。

单步在 SMP 下还有一个特有现象：Step只作用于当前选中的核，其他核保持停止。如果目标代码路径上有一把自旋锁，单步时你会看到程序"卡在 spinlock 里不动"，因为持锁的那颗核没在跑，锁永远不会释放。这不是调试器的问题，是单核单步破坏了多核执行语义。碰到这种情况要么改用组单步，要么先确认这段临界区不依赖别的核推进。

3.4 符号与内存视图的一致性维护

SMP 下四个核共享一份页表，理论上符号加载一次就够。但实际项目里经常见到有人对每个核都跑一遍Data.LOAD.Elf vmlinux，结果是符号表被重复合并，查询变慢、同名符号出现多份、断点解析到错误地址。正确做法是只加载一次，切核不重载。

另一类问题是内核模块。模块的地址是运行时分配的，必须等系统起来之后再加载符号，而且模块卸载后要记得清理，否则符号表里会残留一批指向已释放内存的条目，查询时给出误导性的结果。

4. AMP 与 iAMP 调试流程：多核各自持一套上下文的配置方法

4.1 先分清是跨芯片 AMP 还是片内 iAMP

判断依据是物理链路数量。板上有两颗独立芯片、各自引出调试口，那是 AMP，两套配置互不干扰，可以同时操作。如果所有核都在一颗 SoC 里，共用一组调试引脚，那就是 iAMP，所有操作串行排队，切核等于切换访问目标。

这个区分直接影响脚本结构。AMP 场景下你写两份独立的 .cmm，各自SYStem.CPU、各自 Attach；iAMP 场景下是一份脚本，多个作用域分段，段与段之间有明确的切换点。把 iAMP 当 AMP 写，最常见的报错是第二次SYStem.Mode Attach把已经挂好的核一起带重启了。

4.2 同一 DAP 下多核独立上下文的完整脚本

; iamp_up.cmm —— A核 Linux + R核 RTOS + M核 裸机，共享一个 DAP ; ---- 第一段：A 核，作为 master 建立链路 ---- SYStem.CPU CortexA53 SYStem.CONFIG.DEBUGPORTTYPE DAP SYStem.CONFIG.CORE 0. SYStem.CONFIG.Slave OFF SYStem.Mode Attach Data.LOAD.Elf vmlinux TASK.ACTIVATE Linux ; ---- 第二段：R 核，异构，必须重新声明 CPU 类型 ---- SYStem.CONFIG.CORE 1. SYStem.CPU CortexR52 ; 异构核切换时必须重设，否则按 A 核解码 SYStem.CONFIG.Slave ON SYStem.Mode Attach ; 从核单独挂载，不带复位 Data.LOAD.Elf safety.elf ; ---- 第三段：M 核，裸机，无 OS 感知 ---- SYStem.CONFIG.CORE 2. SYStem.CPU CortexM7 SYStem.CONFIG.Slave ON SYStem.Mode Attach Data.LOAD.Elf m7_fw.elf

这段脚本里最关键的一条是第二段的SYStem.CPU CortexR52。很多人以为 CPU 类型在一份脚本里声明一次就够，结果 R 核的指令被按 A 核的方式解码，反汇编窗口显示出来的全是乱码，断点也设不准。只要核的架构不同，切换作用域之后必须重新声明。

SYStem.Mode Attach在每个从核上单独执行，这一点和 SMP 不同。SMP 是一次 Attach 覆盖整组，iAMP 是每核一次。如果从核的挂载失败，报错只会出现在从核那一段，前面的 A 核不受影响，这也算是个排查上的便利。

4.3 多核同步启停与实时性保护

TRACE32 是"当前核视角"的调试器，所有窗口、命令、断点都跟着 active core 走。CORE.SELECT <n>切换视角之后，反汇编窗口、寄存器窗口、内存窗口显示的都会换成那颗核的内容。这一点在 iAMP 下尤其要注意，因为切核之后地址视图也变了——A 核看到的是虚拟地址，M 核看到的是物理地址，同一个数字在两颗核上代表完全不同的东西。

启停策略上，需要保护实时性的核不要参与全停。做法是先CORE.SELECT到需要停的核，再执行Break，这样其他核继续运行。反过来，如果确实需要多核同时暂停来观察一致性，用组操作，但要提前确认那些实时核停下来的后果可接受——在安全岛场景里，这个确认往往需要和系统负责人过一遍。

4.4 调试动作的作用域检查清单

每执行一次可能改变目标状态的命令之前，按这个顺序确认：当前 active core 是哪一颗、这条命令的作用域是单核还是整组、目标核当前是否在跑、停止它会不会影响别的核的时序。这四条不需要写进脚本，但值得在团队里形成固定的作业习惯——尤其是在 iAMP 这种一条链路服务多个核的结构下，误停一颗实时核的代价，通常比多花十秒确认要大得多。

5. 进阶：多核 trace 触发与跨核时序对齐

跑通 attach 和断点之后，真正能定位疑难问题的能力来自 trace。多核 trace 有一个绕不开的物理约束：每颗核的 trace 源（ETM、PTM 之类）最终汇聚到有限的 trace 输出带宽上，核越多，每颗核分到的带宽越少。抓全四个核的完整指令流，和抓一个核的完整指令流，能覆盖的代码范围完全不是一个量级。所以多核 trace 的第一原则是"用触发缩小窗口"，而不是"全量录下来"。

典型做法是让一颗核的事件去触发另一颗核的采样。比如 A 核进入某个异常处理入口时，把 R 核前后的执行流录下来：

; 多核 trace 触发配置 SYStem.CONFIG.CORE 0. Trace.METHOD Onchip ; 使用片上 trace buffer，不依赖外部探头 Trace.AutoArm ON ; 程序启动即开始采集，避免漏掉早期事件 Trace.Trigger 0x80001234 ; A 核异常向量入口作为触发点 SYStem.CONFIG.CORE 1. Trace.METHOD Onchip Trace.AutoArm ON ; 从核同步开抓，等待交叉触发条件

Trace.AutoArm ON的含义是让采集在程序恢复运行的那一刻自动开始，而不是等人手动下命令。多核场景下这条几乎必须打开，因为两个核的采集起点差几微秒，后面的时间轴对齐就无从谈起。Trace.Trigger指定的是一个地址，当任一被使能的核执行到该地址时，触发缓冲区冻结。

采集完之后，Trace.List用来看指令流，Trace.STATistic用来看核间的执行占比分布。跨核时序对齐是最容易出问题的一环：两颗核的时间戳可能来自不同的时钟域，如果只看各自的时间轴，会得出"两颗核同时执行了同一段代码"这种明显不成立的结论。验证对齐是否可信，有一个便宜又好用的办法——让两颗核在同一时刻翻转同一个 GPIO，然后看两条 trace 里这个 GPIO 写事件的时间差。差值是固定偏移就说明只是时钟域不同，补偿掉即可；差值是抖动的，说明采集本身有丢包，得先回去调带宽和触发窗口。

带宽不够时的取舍顺序：先砍掉不需要的核，再砍 data trace 只留指令 trace，最后才考虑降低采样密度。反过来做，往往是把关键的那笔数据 trace 砍掉了，问题反而看不见。

本文还有配套的精品资源，点击获取