在芯片调试的初期阶段，技术人员经常需要进行目标板bring-up以及底层驱动调试，或者进行多核芯片联调，此时经常会遇到TRACE32目标板连接如何配置，以及TRACE32连接后CPU停不下来怎么办这两个具体问题，并且这两个问题常常同时出现。在实际排查时，这两个现象通常都和芯片型号的挑选、调试接口的选择、复位链路的连通、JTAG时钟的快慢、多核环境的配置以及目标板的硬件状态产生交织。因为TRACE32本身支持的芯片类型和架构非常多，所以Lauterbach公司提供了很多配置好的启动脚本，这些脚本可以帮助技术人员减少手工配置时犯错的概率。
一、TRACE32目标板连接怎么配置
技术人员把线插上目标板，并不意味着TRACE32就能直接进行调试了，其中的关键点在于，软件、调试器、探头、目标芯片以及板子上的复位逻辑这几部分，需要处在同一个能互相沟通的状态里。在进行配置的时候，技术人员不要着急去下载程序，应该首先把基础的连接通路给调通。
1.检查硬件连接与调试探头的匹配情况
TRACE32在工作时，通常需要依赖PowerDebug、对应架构的Debug Cable或者Debug Probe来连接目标板，调试探头必须和目标SoC的调试接口对得上。
目标板的那一端，需要仔细检查JTAG、SWD、cJTAG、DAP、OCDS等接口类型是不是和芯片对得上。很多时候连不上并不是TRACE32软件的问题，反而是板子上的跳帽、拨码开关、调试口的复用设置、目标板的供电或者复位引脚的状态不对。
2.选择正确的CPU型号与启动脚本
在进行连接之前，技术人员要先确定TRACE32启动的是正确的架构版本，比如调试Arm芯片就要打开TRACE32 Arm，调试TriCore或者AURIX芯片就要打开TRACE32 TriCore。
在PowerView界面启动以后，一般的步骤是先去设置具体的芯片型号，然后再去执行连接的指令。
如果把型号选错了，轻微的后果是找不到调试口，严重的后果是虽然连上了，但是寄存器、内存映射以及复位动作都是错的，后续就会引发CPU状态不对、断点点不上去、程序下载完就跑飞等一连串麻烦。
3.采用先低速连接再提高JTAG时钟的办法
面对新做出来的板子或者有故障的板子，技术人员不应该一开始就设置很高的JTAG频率。比较稳妥的做法是先把JTAG的时钟频率调得低一点，比如使用SYStem.JtagClock 100Khz这条指令，等确认系统可以稳定执行SYStem.Up了，之后再一点点把频率升上去。
二、TRACE32连接后CPU停不下来怎么办
有时候TRACE32的界面上已经显示连接成功了，但是技术人员去点击停止按钮、下断点或者执行Break命令，CPU还是在那里拼命跑，遇到这种情况不能只盯着界面上的按钮。技术人员需要先分清楚，这到底是“调试器根本没有控制住核心”，还是说“目标芯片因为复位、看门狗、启动代码或者多核机制的影响一直在被推着跑”。
1.区分SYStem.Up问题与Attach问题
如果系统在运行了SYStem.Up之后控制出现异常，技术人员可以换一个思路，不使用复位的方式去连，而是改用Attach的方式去接入那个正在跑的目标，接着再执行Break。
Lauterbach在关于Arm芯片的排查文档里提到过，如果执行SYStem.Up报错了，可以测试先用SYStem.Mode Attach接入，再执行Break，要是这时候不报错了，那么问题多半出在复位的选项设置上。
2.检查复位线与EnReset的设置
有些板子直接用手去按上面的复位键是可以正常启动的，但是TRACE32执行SYStem.Up之后再点击Go就变得不正常了，这时候技术人员需要重点看调试器控制的那根nSRST复位线，到底有没有真正接到芯片的复位源上。
3.解决看门狗、多核以及启动代码带来的干扰
CPU之所以停不下来，还有一个可能的原因，就是目标程序刚一启动就把看门狗给打开了，或者是安全启动、低功耗模式、锁步核、多核启动代码把调试控制状态给改变了。在Lauterbach的连接排查清单里面也有提到，连接失败的时候需要确认有没有watchdog（看门狗）需要关闭，并且在SMP（对称多处理）的场景里，技术人员应该先尝试只分配第一个核心来进行连接。
三、在TRACE32调试现场建立稳定排查流程的方法
在处理TRACE32问题时，最忌讳的就是“一边试一边改”，今天改一下JTAG时钟，明天改一下启动脚本，后天再换个探头，折腾到最后反而搞不清楚到底是哪个变量改变了结果。比较稳妥的办法是把排查的步骤拆开，分成硬件层、连接层、复位层、运行控制层这四层来逐步推进。
1.确认目标板处于可以运行调试的状态
目标板必须先满足最基本的调试条件，即供电要稳定、VTREF的电压要正确、调试引脚没有被复用到其他功能上去、芯片没有被安全机制锁死，以及启动模式没有进入到无法调试的状态。当JTAG链路检测不通过时，技术人员可以在Down状态下运行daisy chain（菊花链）检测，以此来确认链路里面能不能看到预期的调试设备。
2.将启动脚本拆分开来进行段落验证
技术人员不要在一开始就去直接运行一整段完整的.cmm脚本。因为一个完整的脚本里面通常包含了CPU型号选择、JTAG频率设置、复位选项、内存初始化、Flash算法配置、符号加载以及断点设置等一堆动作。连接出现异常的时候，最好的办法是把脚本拆成几段来运行，先保证程序能跑到SYStem.Up且CPU能停下来，之后再去加载ELF文件或者符号文件。
3.做好状态栏信息与停止原因的记录工作
TRACE32状态栏里面显示的stopped、stopped by breakpoint、stopped by XXXevt这些字样并不是随便写写的，它们反映了CPU此时此刻的状态，以及进入这种状态背后的原因。对于TRACE32这种非常底层的调试工具而言，技术人员的排查思路只要清晰一点，就不容易被表面的古怪现象给带偏方向。
结论
针对TRACE32目标板连接怎么配置这个问题，核心要领并不是把那几条命令死记硬背地敲一遍，而是要确保硬件探头、芯片型号、调试接口、JTAG时钟、复位线以及启动脚本这些要素全都能对得上。而对于TRACE32连接后CPU停不下来怎么办这个问题，技术人员也不能简单地认为是软件坏了，常见的诱因包括复位信号没有真正传递到SoC上、Attach和Up两种模式的行为有差异、JTAG频率设得太高了、看门狗在作祟、多核核心选错了，或者启动代码走得太快导致核心状态改变了。
