调试多核程序时，一个核命中断点，另一个核还在修改共享数据，停下来看到的现场就可能已经发生变化。也有些工程从核尚未启动，窗口却显示运行状态，容易被误认为同步失效。检查TRACE32多核同步配置时，需要把实例连接、运行控制和芯片状态分开核对，并通过明确的停机动作验证，不能只凭几个窗口的显示结果下结论。

　　一、Trace32怎样检查多核调试同步配置

　　TRACE32可以在一个界面中管理多个核，也可以通过多个PowerView实例分别控制。不同调试模式的检查入口不同，应先确认当前工程采用哪种组织方式。

　　1、确认实例与处理器核的对应关系

　　单界面管理多个核时，应检查核分配；多个实例分别调试时，还要核对实例之间的同步连接。窗口数量与芯片核数未必一一对应，一个实例也可能管理整个核簇。

　　①查看启动脚本中的【SYStem.CPU】和【SYStem.CONFIG】配置，记录各实例负责的处理器核或核簇。

　　②对SMP配置执行【CORE.List】，并核对脚本中的【CORE.ASSIGN】或【CORE.NUMber】。

　　③检查是否使用了【CORE.SINGLE】等单核调试设置，确认本次测试包含哪些核。

　　④对多个PowerView实例分别记录名称、核归属及InterCom端口。

　　2、核对实例间的通信连接

　　①检查各实例启动配置中的【IC=NETASSIST】及其【PORT】设置，为同机实例分配不同端口。

　　②在实例A执行【SYnch.Connect localhost:20001】，其中端口替换为实例B的实际InterCom端口。

　　③打开【SYnch.state】，核对连接对象；需要双向操作时，在另一实例中检查反向连接。

　　④使用【InterCom.PING】配合对端地址验证通信，再检查连接清单。

　　连接成功只说明实例具备协作基础，还要继续检查具体动作的同步开关。地址也必须指向对方实例，不能把本实例端口写成连接目标。跨主机连接时，应核对主机地址及UDP通信条件。

　　3、分别检查运行、停机和单步开关

　　①在发起停机的实例检查【SYnch.MasterBreak ON】，在接收实例检查【SYnch.SlaveBreak ON】。

　　②需要同步运行时，分别检查【SYnch.MasterGo】与【SYnch.SlaveGo】。

　　③需要汇编单步联动时，再检查【SYnch.MasterStep】与【SYnch.SlaveStep】。

　　④回到【SYnch.state】，确认连接机制已启用，并按预期操作方向复核两端设置。

　　这些开关可以独立配置。一个窗口能够带动其他核运行，不代表停机方向也已配置完整。Master、Slave在这里描述发送与接受某类同步动作的角色，同一实例可以同时承担两种角色，不应直接等同于芯片的主核和从核。

　　二、Trace32多核停机状态不一致时如何定位原因

　　发现不同核状态不一致后，应先区分持续无法停止、短暂停止延迟，以及目标核根本不可访问。它们需要检查的配置并不相同。

　　1、用手动停机区分同步问题与目标问题

　　①让参与测试的核进入已知运行阶段，在实例A执行【Break】，观察实例B。

　　②按原有运行顺序恢复执行，再从实例B发起【Break】，检查反向效果。

　　③若某实例未停，在该实例直接执行【Break】，记录是否返回【emulation running】等信息。

　　④重新打开两端【SYnch.state】，检查脚本运行后设置是否发生变化。

　　只有一个方向失效时，应重点核对发送端和接收端的配对设置。目标实例自身也无法停机，则应转向核状态与调试访问检查。初始化脚本中的同步复位、断开连接或关闭同步命令，也可能覆盖之前的手动设置。

　　2、检查复位、掉电及调试访问状态

　　在部分Arm系统中，状态栏出现running并不代表处理器核正在正常执行指令，括号内的说明更有判断价值。

　　①记录状态栏完整内容，区分【running(power down)】、【running(no CPU)】和【running(no CTI)】等状态。

　　②核对芯片的电源、时钟及复位状态寄存器，检查从核是否已经释放。

　　③按芯片初始化流程检查从核唤醒步骤，并确认安全状态或调试锁是否阻止访问。

　　④待目标核可访问后，先验证单独停机，再恢复多核同步测试。

　　处于掉电或复位中的核无法按普通运行核处理。某些Arm状态还表示停机请求已经挂起，等待核恢复供电后生效。不能仅凭窗口显示不同，就反复切换同步开关或修改调试连接。

　　3、判断采用硬件同步还是软件同步

　　①查阅目标处理器手册，确认是否具备跨核停机单元及对应调试支持。

　　②对Arm平台，核对初始化脚本中的【SYStem.CONFIG】、【CTI.Base】和【CTI.Config】等适用配置。

　　③检查同步组包含的核，以及交叉触发资源是否能够覆盖这些连接。

　　④重复短距离运行与停机测试，比较各核停止后的状态和程序位置。

　　软件同步通常逐个停止目标，会存在时间差；硬件同步能力则受芯片实现和触发连接限制。不同核执行不同代码，即使协调停机，程序计数器也不需要相同。若问题依赖共享数据变化的精确先后，应结合可靠时间戳的跟踪记录分析。

　　三、Trace32怎样验证多核断点联动与启动顺序

　　手动停机通过后，还应检查断点命中和启动阶段。两个核已经进入业务代码时同步正常，不代表从复位开始就适合使用同一套联动设置。

　　1、验证各核命中断点后的联动结果

　　①在核A必经位置使用【Break.Set】设置测试断点，运行后检查其他参与核是否停止。

　　②在核B设置独立测试断点，验证反向联动。

　　③在停机后查看【CORE.List】或各实例状态栏，记录停止状态与程序位置。

　　④打开【Break.List】，检查测试断点及其附加命令，排除命中后自动继续运行的设置。

　　验收时应分别测试人工暂停与断点停机。停机后的列表可用于核对各核位置，但不能用作持续运行期间的实时核状态监视。测试结束后，也应移除临时断点，避免影响正式复现。

　　2、按芯片启动依赖安排同步时机

　　①对照启动流程，检查【SYStem.Up】、从核释放及应用加载的执行顺序。

　　②在需要握手的阶段，按芯片要求分别运行相关核，确认释放条件已经满足。

　　③待参与核进入可调试状态后，再配置【SYnch】运行与停机联动。

　　部分芯片需要一个核执行到特定位置，才能释放另一个核。过早要求所有核一起运行或停止，可能打断这个过程。同步运行、同步停机和系统模式联动应分别评估，避免把复位操作也无条件传播到其他实例。

　　总结

　　TRACE32多核同步是否有效，需要结合实例拓扑、动作方向和处理器状态判断。日常配置可以围绕实际调试目标确定参与核，再分别验证运行、手动暂停和断点联动。遇到状态不一致，完整记录状态栏说明，并检查目标能否单独停止，通常能较快缩小范围。对精确时序问题，还应了解硬件与软件同步的能力边界。希望这些方法能帮助你稳定保留多核现场，后续也可以结合具体芯片细化启动和停机配置。