板卡刚上电进行调试的时候，如果启动脚本的先后顺序编排得不怎么稳当，经常会表现出来的现象包括：连接一会儿好一会儿坏，芯片复位之后程序自己跑飞掉，或者明明符号已经加载成功了，可断点就是打不进去。关于TRACE32的启动脚本该如何去编排，以及上电以后的初始化顺序怎样去确认，比较合理的做法是把一整段PRACTICE脚本拆分成连接、目标初始化、程序加载、调试配置跟运行控制这么几个部分。TRACE32里头的PRACTICE脚本，它的主要用处是拿来做自动配置、测试自动化，还有把系统设置给保存下来，这类脚本一般都会存成.cmm文件，既可以在命令行下用DO命令直接去跑，也能够让别的脚本去调用它。

　　一、TRACE32启动脚本怎么编排

　　启动脚本最忌讳的就是把所有的命令不分层次地堆在一块儿，因为板卡不同、供电方式不同，还有CPU型号和启动方式这些因素，都会让脚本在细节上有所变化，但不管怎么变，它整体的层次结构是能够保持相对稳定的。

　　1、先清理旧状态

　　在脚本的开头，我们可以先把前次调试会话里留下来的那些窗口、断点还有显示状态什么的清干净，一般会用上RESet和WinCLEAR这两个命令。假如调试的是多核芯片，那就还要先去查一下当前连接着的到底是哪一个内核，免得脚本跑着跑着跑到错的实例上去了。

　　2、配置CPU和连接方式

　　接下来要把SYStem.CPU、调试用的端口、JTAG的时钟频率，还有复位的方式以及芯片相关的一些选项都给配好。官方的架构手册里头一般都会建议，在目标板上电之后，靠启动脚本来对调试器完成配置；而且TRACE32本身也提供了不少现成的板卡脚本，我们可以在命令行那里敲入WELCOME.SCRIPTS，或者顺着菜单【File】→【Search for Script】去把它们找出来用。

　　3、建立调试连接

　　在需要靠调试器去控制复位动作，并且要让芯片停在调试状态的时候，我们用的指令往往是SYStem.Up；可如果目标上的程序本来就已经在跑了，而我们只打算挂上去观察一下，那就要根据具体的平台去选用Attach这一类的方式，千万别一上来就去复位目标，否则会把正在跑的程序打断。有部分平台上面，SYStem.Up到底会不会真的去拉低硬件的复位信号线，还得看SYStem.Option.EnReset这个选项有没有打开，同时也要确认调试器的复位线是不是正确地连到了芯片的复位源头那里。

　　4、执行板级初始化

　　等到连接成功地建立起来以后，我们再去接着做时钟、内存控制器、外设的门控、看门狗，还有片上RAM这一堆东西的初始化工作。比较推荐的做法，是把板级初始化的这些动作单独抽出来，存成一个叫board_init.cmm的文件，然后在主脚本里面用DO命令去调用它。这样一来，往后要换另一种板卡的时候，就只需要改动那一段就好了，主流程不会被搅乱。

　　5、加载程序和符号

　　如果程序是准备下载到RAM里去跑的，那就可以拿Data.LOAD.Elf这个命令来干活；要是程序早就已经烧到Flash里头去了，只是想挂上符号信息方便调试，那就可以根据当前的平台，去选用那种只加载调试信息的方式。Data.LOAD.Elf这个命令，它专门负责从一个文件里面把程序搬到目标的内存里头，具体要带哪些选项，得结合启动介质的实际情况来定。

　　二、TRACE32上电初始化顺序怎么确认

　　上电初始化的顺序正不正确，不能光盯着脚本有没有跳出错误提示就算了，更要把目标板在各个阶段里的状态，一段一段地去确认清楚。最容易惹出麻烦的几个地方，无非就是复位信号释放得太早了、内存的初始化还没来得及做完就急急忙忙去加载程序，再就是符号文件的版本跟板子上实际跑的程序版本对不上。

　　1、先确认硬件上电链路

　　平常比较常见的上电顺序是这样的：先依次把主机、TRACE32硬件，还有调试线都给连好；然后启动TRACE32的软件，把调试器的固件装载进去；接着让它跟目标板建立连接；最后一步，再给目标板送上电，并且执行启动脚本。各个不同架构的手册几乎都会提醒一句，插拔调试线这个动作，一定要在目标板断电的状态下来做。

　　2、分段执行脚本

　　头一回调试一块新的板子的时候，最好不要一上来就整段脚本DO下去。可以按照连接、复位、寄存器初始化、内存检查、程序加载，再往后设置断点这样的顺序，一段一段地分开来跑。每跑完一小步，就用Data.dump、Register.view这些命令，或者直接查看状态窗口，去核对一下跟前的结果是不是预期的样子。

　　3、确认复位后停在哪里

　　执行了SYStem.Up之后，先瞧一瞧程序计数器指的地址，是不是正好落在手册上写的那个复位入口上，另外那些关键的寄存器里面的值，也要跟芯片手册里讲的核对一下。要是目标板通过按实体复位键能够正常跑起来，可用SYStem.Up再加上Go这一套却启动不了的话，那就要把排查的重点放在EnReset的设置、复位线的连接还有复位之后的初始化流程上面了。

　　4、确认内存可读写

　　在正式去加载程序之前，我们最好先挑一小块目标上的RAM出来，做一下简单的读写测试。如果连内存控制器都还没有配置好，就急着去跑Data.LOAD.Elf，那十有八九是要失败的，就算表面上看着是下载成功了，等真正运行起来，也很可能马上就出现异常。

　　三、TRACE32启动脚本异常怎么排查

　　就算脚本已经可以跑起来了，也并不代表它里头的顺序就一定靠得住。我们得在每一个关键的节点那里，都给后续的检查留出可以插手的空间。

　　1、把脚本拆成多个文件

　　一个比较推荐的做法，是保留好main.cmm、connect.cmm、board_init.cmm、load.cmm，还有debug_setup.cmm这么几个文件，让主脚本只负责去管调用它们的顺序，而把跟板级相关的寄存器配置单独放到一边去维护。

　　2、增加停止点和提示

　　还在新板验证的那个阶段，我们可以在一些关键的地方，加上像PRINT、WAIT这样的命令，或者干脆安排一个人工确认进去，好让脚本能够在那里先停一停，等我们看完目标板的状态再接着往下走。等到一切都稳定下来之后，再一步一步地把这些地方都改成自动执行。

　　3、保留安全启动入口

　　万一碰到脚本一上来就卡壳的情况，我们可以用T32Start里面那个Safe Start的功能，先把自动跑PRACTICE脚本的动作给压住，然后再用手工一段一段地去调试。T32Start本身还支持指定一个启动脚本，同时也能把事先设好的参数传给它。

　　4、检查符号和固件版本

　　要是出现脚本连接看起来一切正常，可断点的位置却跟预想的不太一样，这种时候，头一件事就是去核对一下ELF文件、Flash里面烧的程序，还有源码这三者之间的版本是不是一致的。只要符号文件不是跟当前板上固件同一个版本的东西，那往后看调用栈和变量的时候，得到的结果就都会出现偏差。

　　总结

　　总的说来，只要把板卡的启动脚本写得清清楚楚，往后去定位问题的时候，感觉就会轻松一大截。关于TRACE32启动脚本到底该怎么编排，可以大致按照清理状态、CPU配置、建立连接、板级初始化、加载程序、调试配置，一直到运行控制这样的流程来把它拆开；而要去确认TRACE32上电初始化的顺序正不正确呢，就得一段一段地去检查复位的入口、关键寄存器的值、RAM的读写还有符号的版本。新板子头一回接入的时候，花上一点时间慢慢地分段去验证，等到后面要批量调试的时候，反倒能帮你省下更多的时间。