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

很多人把IAR和TRACE32放到一起用时，最容易把“编译输出”“符号加载”“源码映射”当成三件分开的事来处理，结果工程能编过，调试却总是函数名不全、源码打不开、断点落不准。实际上这三步在工具链里是一条线。IAR当前Arm版工程默认支持生成带DWARF调试信息的ELF输出，Lauterbach这边则是通过`Data.LOAD.Elf`把代码、符号和调试信息一起读进TRACE32；如果板子上程序已经烧好，还可以只装符号不下载代码。

很多人碰到Trace32连不上目标板时，第一反应是软件配置有问题，但真正高频的根因往往在最底层：接口线接错了，VTref没接到目标I/O电源，地线没并好，复位脚悬空，或者上电顺序把调试口带进了异常状态。Lauterbach官方资料对这类问题的判断逻辑很明确，TRACE32要先看到调试接口上的参考电压，才能正确判断目标板是否上电并匹配调试信号电平；如果VTref没有被检测到，PowerView就会报出target power fail或power down。

很多人说的Trace32日志，其实常见有三类：一类是消息区内容，主要用来回看报错与提示；一类是命令或界面操作记录，用来复现你点过什么与执行过什么；还有一类是系统访问级别的SystemLOG，用来记录Trace32自身访问与行为。你看到空白时，往往是打开方式和记录对象没对上，按下面顺序对齐即可。

Trace32的Trace能不能录到东西，取决于两件事是否同时成立：一是目标侧有没有真正生成Trace数据，二是调试器侧有没有把Trace数据抓进缓冲并正确解码。很多现场的表现是看起来已经连上也点了开始，但Trace窗口里一片空白，这通常是生成与采集其中一步没走通，按固定顺序核对会更快收敛。

多核调试里所谓的不同步，通常不是工具失灵，而是调试模式与实际系统形态不匹配，或者多实例联动机制没有建好：你看到的现象可能是某个核在跑、另一个核停在断点，或你切换到某个核的视图后发现寄存器与符号似乎对不上。把问题拆开看，一半是选对SMP、iAMP、AMP这三类工作方式，另一半是把核映射、实例联动、核选择这些细节做扎实，现象往往就能解释清楚并稳定复现。

TRACE32里断点无法命中，很多时候并不是断点功能失效，而是断点类型选错、断点资源用尽、地址映射与上下文不一致，或缓存让处理器看到的指令与调试器改写的内存不一致。把问题按断点落点、断点实现方式、缓存一致性三条线拆开排查，通常能很快把范围缩到一两个明确的根因，并给出可复现的修复动作。