TRACE32已连接目标板，反汇编窗口却只显示地址，函数列表里也找不到预期名称。先核对符号文件是否对应板上固件，再看函数是否进入符号表，最后比较符号地址与程序实际执行地址。以下以ELF文件为例。

TRACE32通常使用PRACTICE脚本保存处理器选择、调试接口、程序装载和断点等操作，文件一般使用.cmm扩展名。工程换目录、升级TRACE32后，如果脚本不再自动执行或运行到中间停止，可以先确认脚本有没有被调用，再检查路径、命令和目标板状态。

使用TRACE32烧写Flash，连接成功只是起点，芯片脚本、Flash地址、目标RAM、看门狗、缓存和程序文件还要逐项匹配。下面围绕“TRACE32怎么烧写Flash程序TRACE32烧写Flash失败如何检查配置”展开，直接按照实际操作顺序说明烧写与排查方法。

调试人员在用TRACE32这个工具看芯片启动的时候，复位操作表面上就是点一下那个【Reset】按钮，或者在控制台敲一个SYStem.Up命令，但是其实里面有很多别的事情在影响最后的结果。大家要是碰到TRACE32复位流程怎么配置，或者TRACE32复位后程序入口跳转异常怎么办这类情况，调试人员不能光看程序最后有没有重新跑起来，还要去检查复位具体是用哪种方式搞的，调试器和板子是怎么连上的，CPU有没有死死停在reset vector这个地方，PC寄存器的初始数值对不对，以及向量表和启动地址到底能不能对得上。

在对嵌入式程序进行调试的时候，TRACE32中变量观察怎么添加，以及TRACE32中变量被优化后看不到该怎么办，这两个问题经常会被大家遇到。表面上看起来这只是变量窗口的使用问题，但是这其实和ELF符号、当前停机的位置、函数的栈帧以及编译优化的等级都有关系。也就是说，并不是只要把变量名输入到TRACE32里面就一定可以显示出数值，调试器还需要知道变量的具体位置，当前代码运行到了哪里，以及这个变量有没有被编译器给保留下来。

在使用TRACE32调试MCU、SoC或嵌入式Linux程序时，很多问题不是程序没有下载进去，而是符号信息没有正确加载。遇到“TRACE32符号文件怎么加载TRACE32符号加载后函数名不显示怎么办”这类情况，需要把程序镜像、ELF调试信息、加载地址、编译选项和TRACE32窗口显示方式一起检查，不能只盯着一个加载命令看。

在调试那些跑着实时操作系统的程序时，光盯着寄存器和函数调用往往是不够的，我们还得弄清楚当前是哪个任务在跑、任务处在什么等待状态、它的优先级是多少，以及栈空间的使用情况。TRACE32的OS Awareness功能要怎么开启，如果任务列表显示不全又该怎么办，处理这些问题的时候，首先要确认操作系统的类型，然后再加载对应的扩展文件。根据TRACE32通用命令的参考说明，OS Awareness是由TASK.CONFIG来配置的，这个命令会载入与内核相关的各种信息；不同的操作系统，它们所支持的资源窗口还有命令也是有所区别的。

在多核芯片调试的时候，不少人会把“把调试窗口切换到某个核心上去看它里面寄存器的状态”和“只让这一个核心运行、把其他核心都停住”这两个动作当成一回事。要用TRACE32同时调试多个核心，得先把两个基本的事情理清楚：一个是怎么在不同核心之间来回切换，让调试器显示我们想看的那个核心的上下文；另一个是怎么控制多个核心同步地启动和停下来。而要弄清楚这两点，最要紧的一步就是先判断当前的系统处在哪种模式下，是对称多处理（SMP）模式，还是非对称多处理（AMP）模式。TRACE32本身是能够同时挂载好几颗核心一起来调试的，你可以让所有核心同步动作，也可以只盯着其中某一个核心的状态，前提是把下面这些设置和命令弄对了。

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

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