TRACE32里脚本看起来“没生效”，很多时候并不是脚本语法本身有问题，而是启动入口、当前工作目录、搜索路径和文件访问权限没有对齐。Lauterbach官方资料里把这几层关系讲得很清楚：启动时会先自动执行`autostart.cmm`，它还会继续调用系统级、用户级和工作目录下的启动脚本；手工执行`DO`时，又会先看当前工作目录，再看`PATH.Set`定义的搜索路径；如果你改用`ChDir.DO`，这些PATH路径还会被直接绕开。只要这几层没分清，脚本明明在磁盘上，TRACE32也可能表现成“没有执行”。

　　一、Trace32脚本不生效怎么办

　　先别急着改脚本内容，第一步要先判断它到底是“没被调用”，还是“被调用后中途报错停掉了”。官方文档已经给出很直接的排查入口，顺着走通常就能很快缩小范围。

　　1、先核启动方式

　　如果你靠启动自动执行脚本，先看是不是走了`autostart.cmm`，还是通过`-s`指定了别的启动脚本。官方还特别说明，`--t32-safestart`会直接禁止`autostart.cmm`和其他启动脚本执行，所以一旦开了这个参数，再去等脚本自动生效，结果一定不对。

　　2、再看脚本实际放在哪

　　官方默认会自动找三类启动脚本，也就是`~~/system-settings.cmm`、`UAD/user-settings.cmm`和当前工作目录下的`./work-settings.cmm`。如果你的脚本本来想做全员通用设置，却放到了工作目录里，那换一个启动目录后它自然就“不生效”了。

　　3、手工执行时先看当前目录

　　`DO abc.cmm`不是全盘乱找。官方说明里，TRACE32会先在当前工作目录找，再去`PATH.Set`定义的搜索路径里找。排查时先用`PWD`看当前工作目录是不是你以为的那个目录，再用`PATH.List`看搜索路径里到底有没有你的脚本目录。

　　4、如果用了ChDir.DO，要意识到它会绕开PATH

　　这点特别容易漏。官方明确写到，只要你把`ChDir`放在命令前面，例如`ChDir.DO`，那么通过`PATH`定义的搜索路径就会被省略。也就是说，平时`DO test.cmm`能跑，改成`ChDir.DO test.cmm`后找不到文件，并不奇怪。

　　5、先把错误消息完整抓出来

　　TRACE32的异步错误都会写到默认消息区A000。官方建议可以直接`AREA.view A000`看消息窗口；如果想留完整证据，还可以用`AREA.OPEN A000`把输出流到日志文件，再配合`LOG.toAREA ON/ALL`把触发错误的命令和错误文本一起记下来。这样排查时就不会只剩一条转瞬即逝的红字。

　　二、Trace32脚本路径与权限怎么排查

　　路径问题和权限问题，表面上都像“脚本没反应”，但处理思路并不一样。路径问题更像是找不到文件，权限问题更像是找到了但读写动作被操作系统拦住。官方错误手册已经把最基本的文件异常区分开了。

　　1、先排路径，不要先怀疑语法

　　如果TRACE32报`filenot found`，官方解释就是文件不在当前路径或指定路径里。这时先核三件事：当前工作目录是不是对的，`PATH.Set`里有没有脚本目录，命令里是不是写了相对路径或过时目录。尤其旧脚本还指向废弃demo目录时，官方错误手册也会直接给出对应提示。

　　2、再排读写权限

　　官方在文件对话框相关命令里明确写到，打开文件默认假定你有读权限，保存文件则假定你有写权限。对脚本排查来说，这意味着脚本所在目录如果没有读取权限，或者日志输出目录没有写入权限，结果都可能表现成脚本执行异常。所以除了脚本文件本身，还要顺手检查脚本里引用的配置文件、日志文件和导出目录。

　　3、含空格路径要特别小心

　　官方在文件对话框说明里专门提醒过，带空格的文件名或路径读取时要按整行方式取值。放到PRACTICE脚本里，这类路径如果拼接不规范，最容易出现“文件明明在，但命令拆成两段”的问题。路径一旦带空格，最好全程按完整文件名处理，不要图省事。

　　4、先用编辑器直接打开脚本本体

　　如果怀疑脚本路径或权限有问题，先用`EDIT.OPEN`或`PEDIT`把同一个脚本文件直接打开。能正常打开，至少说明当前路径和读取权限大体没问题；打不开，就先别继续查业务逻辑，而要回到文件位置和访问权限本身。

　　5、脚本里引用其他脚本时，要把子脚本路径一并查掉

　　很多“主脚本能跑但结果不对”的情况，最后不是主脚本错，而是它里面`DO`进去的子脚本没找到。PATH搜索规则、工作目录和`ChDir.DO`的影响，对子脚本同样成立，所以排查时不要只看入口脚本，要把它继续调用的文件一起列出来核。

　　三、Trace32脚本调试时先从哪里下手

　　真正要把问题查快，最稳的顺序通常不是盯着代码猜，而是先证明确实进了脚本，再看执行到了哪一行，然后再看宏和调用链。官方给的PRACTICE调试命令正好就是围着这条线设计的。

　　1、先开单步

　　用`PSTEP`可以把PRACTICE脚本切到单步执行模式，再启动脚本。这样你能直接判断脚本有没有真的进入执行，而不是只靠界面感觉它“像是没跑”。

　　2、再用PLIST看当前位置

　　`PLIST`可以显示当前正在执行的PRACTICE脚本，并把当前位置列出来。对排查来说，它最有价值的地方不是看代码，而是确认TRACE32当前到底停在了哪一个脚本、哪一行。

　　3、关键位置加断点

　　如果脚本很长，直接用`PBREAK.Set`在可疑行打断点会更快。官方还给了`PBREAK.List`来统一查看所有脚本断点，适合排查入口函数、路径切换和加载动作这几类关键步骤。

　　4、宏和作用域一起看

　　很多脚本“不生效”，不是命令没跑，而是参数宏没有按预期传下来。官方说明里，`PMACRO.list`可以查看PRACTICE栈、脚本嵌套和宏内容；如果怀疑老宏污染当前脚本，还可以用`PMACRO.RESet`清掉当前层宏再重试。

　　总结

　　Trace32脚本不生效，先别上来改语法，先把启动入口、当前工作目录、PATH搜索路径和消息窗口这几层核清楚。Trace32脚本路径与权限怎么排查，最稳的顺序就是先用`PWD`、`PATH.List`、`AREA.view A000`和日志把“找没找到、执行到哪、报了什么错”固定下来，再用`PSTEP`、`PLIST`、`PBREAK.Set`和`PMACRO.list`去看脚本执行细节。把这套顺序守住，大多数所谓“脚本不生效”的问题，最后都会落回到路径、启动方式或文件访问这一层，而不是脚本语言本身。