调试环境里如果每次都要手动去点菜单，来做初始化、下载程序、设断点、跑自动化检查这一整套动作，其实是很容易漏掉某个步骤的。想让这些操作自动完成，就要用到TRACE32里的PRACTICE脚本，而很多人比较关心的就是这类脚本到底怎么跑起来，以及万一运行的时候报了错，该从哪些地方下手去查。在动手之前，需要先把脚本的入口在哪、工作目录对不对、参数是不是传全了，还有目标芯片当前的状态，这几件事理清楚，后面会少走很多弯路。按照Lauterbach官方的说明，PRACTICE脚本主要是拿来做自动化配置、自动化测试序列，以及保存系统设置的；在命令行那里，用【DO】命令就可以启动一个PRACTICE脚本，在脚本里面，也照样能用【DO】去调用另一个脚本，一层层配合起来。
一、PRACTICE脚本可以怎样运行
PRACTICE脚本通常都是.cmm文件。准备运行之前，不能光看文件名就点下去，得先确认一下这套脚本适不适合手头的芯片、调试接口、工程路径和TRACE32的版本，否则即使脚本能顺利启动，也可能跑到加载符号或者连接目标这一步的时候，就直接失败了。
1.从命令行启动脚本。在TRACE32 PowerView界面底下的命令行里，敲入【DO脚本路径】就能把它跑起来，比如可以一口气完成初始化、加载elf文件、设置断点、让程序开始运行这些操作。官方参考里面也说到，【DO】默认就是用来启动.cmm脚本的，脚本内部要再去调用别的子脚本时，一样可以用【DO】，而被调用的那个脚本，一般都会用【ENDDO】来收尾。
2.先把工作目录确认好。如果脚本里面写了一些相对路径，比方说用来加载工程文件、符号文件或者配置文件的地方，这些东西能不能找到，就要看当前的工作目录是不是设对了。一个比较稳妥的办法，是在脚本的开头就做好目录切换，或者干脆把关键的几个文件路径写成绝对路径，这样换了电脑也不会因为目录不对而卡住。
3.检查一下参数有没有传入。有的脚本是会接收参数的，像芯片型号、elf文件存放的位置、测试模式这一类的东西。在运行之前，可以先翻到脚本开头瞄一眼，看看有没有【ENTRY】或者用宏变量定义了什么参数。要是参数没传进来，后面很可能不会马上报错，而是跑到加载文件、设置地址或者做条件判断那些步骤时，问题才突然暴露出来。
4.新脚本分段慢慢跑。刚拿到一份之前没接触过的脚本，最好不要一下子就把整条流程全部跑完。可以先把连接目标、复位、加载程序这几个最基本的动作保留下来，等确认环境已经稳定了，再一步一步地把后面的断点、运行和验证动作打开，这样更安全一些。
二、脚本报错时该从哪些地方查起
当PRACTICE脚本跑出了错误，一个比较合理的排查顺序是：先看错误输出窗口，再看提示的那一行，然后看脚本当前到底执行到了哪个位置。不要只盯着最后一句错误信息去判断，因为真正的问题很可能出在更前面的一条路径、一个宏变量，或是目标当时的状态上。
1.先看看AREA消息窗口。在TRACE32里面，错误文本和用PRINT命令打出来的信息，都会被送到消息区域里。官方的PowerView命令参考里也说明了，AREA窗口就是用来显示输入和输出消息的，可以看到错误文本、PRINT命令的输出，还有一些异步的错误信息；如果一下子弹出来好几个错误，跑得很快，就可以用【AREA.view】命令把消息窗口重新调出来仔细看。
2.按文件名和行号去定位。如果错误提示里写明了是哪一个文件的哪一行有语法问题，那就直接打开那个.cmm文件，对着那一行去核对。Lauterbach的错误信息文档里面提到过，类似“PRACTICE syntax error in file
3.用PLIST来调试脚本。把【PLIST】窗口打开以后，就能看到当前脚本执行到哪一行了，而且还能在脚本行上面设断点。按照官方用户指南里的说法，在PLIST窗口里对整行双击一下，就可以把PRACTICE脚本的断点打开或者关掉，在右键菜单里也能找到Toggle breakpoint这个选项。
4.查一下宏变量和块结构。常见的错误还包括宏变量忘了声明、用括号围起来的块没有正确闭合、GOTO跳到了不对的层级、命令太长、或者某条命令不被当前版本支持。碰到这类问题，一个比较直接的办法是把那些复杂的语句先拆短，然后按顺序把变量声明、条件判断和循环块一段一段地检查，就容易发现问题。
三、为什么脚本换了一台环境就失败
有的脚本在作者自己的电脑上能正常跑，可是一换到测试机上就失败了，这很少是由单一原因造成的。大多数时候，是因为路径、版本、目标连接状态、文件权限，还有时序上的等待，这几样东西没有对齐。
1.检查文件路径。在加载elf、s19、map或者配置文件的时候，要确认那些文件是不是真的在对应的位置。相对路径在不同的启动目录下面，会指向不同的地方，所以像这类比较关键的文件，路径最好写清楚，别让软件去猜。
2.检查目标是不是已经就绪。复位、连接、下载程序、开始运行这几个步骤之间，要留出必要的等待时间。脚本跑得太快，目标芯片还没停稳，下一条命令就拍过去了，接下来就很容易碰到断点无效、符号没加载上，或者内存访问失败这类问题。
3.检查一下版本差异。不同的TRACE32版本、不同的CPU包、不同的芯片配置文件，它们能支持的命令和实际行为，不一定会完全一样。如果遇到“command not supported”这样的错误，就要去核对一下当前安装的版本，和写这份脚本的那个环境是不是一致。
4.保留一份最小的复现脚本。可以把跑失败的那份脚本，压缩成连接目标、加载文件、执行出问题的那条命令，就这么几步。然后把AREA窗口的输出、PLIST指到的行号，还有工程路径这几点记下来，这样不管是在内部排查，还是把信息提交给工具支持那边，都比直接丢过去一整套大脚本要好定位得多。
总结
关于TRACE32的PRACTICE脚本怎么运行，以及脚本报错以后该从哪些地方查，核心就是靠【DO】来启动.cmm文件，靠【AREA】窗口看错误输出，靠【PLIST】去定位脚本行和设调试断点。拿到新脚本的时候，先分段运行，报错之后，再按路径、参数、宏变量、目标状态，还有版本差异这几项，逐一检查。把这些基础的东西理顺了，PRACTICE脚本就能稳定地撑起调试的初始化和自动化测试，而不只是简单地执行几条命令。
