TRACE32在调试FreeRTOS、AUTOSAR OS、Linux以及其他受支持操作系统时，可以通过OS Awareness读取内核中的任务控制信息，并显示任务名称、状态、优先级、当前运行核心等内容。打开任务列表后只看到部分任务、任务名称为空、状态栏出现task error，或者某些任务字段缺失时，应先确认OS Awareness已经加载，再检查内核符号、地址转换和操作系统初始化状态。

TRACE32配置多核调试时，核心数量并不是唯一依据。各核心是否运行同一操作系统、是否需要独立启停、是否共享地址空间，都会影响调试模式。处理“TRACE32怎么配置多核调试TRACE32多核同步调试异常如何排查”时，应先确定SMP或AMP，再配置核心编号、实例通信和同步动作，后续异常才容易定位。

在 TRACE32 调试时，内存窗口不仅能看 RAM、外设寄存器、栈区和全局变量区，有些场景下也可以直接改内存内容。遇到“TRACE32内存窗口怎么修改 TRACE32内存写入失败怎么处理”，不要只理解成窗口里改不了数值。它背后可能涉及 CPU 是否停机、地址是不是有效 RAM、访问宽度是否正确、当前 access class 是否匹配、目标芯片是否开启了写保护，以及写入区域到底是 RAM、Flash 还是外设寄存器。

在对多核心芯片进行调试的时候，调试人员不能简单地认为只要连上一个内核再点击运行就可以了；调试人员首先需要明确当前芯片到底是使用的SMP模式、AMP模式，还是混合多核心的办法在运行；如果调试人员把模式选错了，在后续的过程中，就容易碰到某个内核停下来了而另一个内核还在继续跑的现象，或者断点明明被触发了，但是窗口里面显示出来的却不是调试人员想要看的那个目标核心。

当调试环境突然弹出许可证异常的提醒时，先别急着去换启动脚本，我们要先弄清楚TRACE32许可证该怎么检查，以及它到期之后功能上到底会受到哪些影响。这个时候需要把两种情况分开来看：一种是软件的服务保障期已经结束了，另一种则是当前的调试核心压根儿就没有对应的许可证。这两种情况都会给出提示，但它们各自影响的范围其实是不一样的。

在调试Bootloader、应用程序、操作系统的镜像，或者那种分成好几段的固件时，常常会碰到符号文件该怎么加载进去，以及符号里头的地址跟板上实际运行的地址对不上该怎么去修正的问题。在TRACE32这个调试工具里面，当你加载一个ELF或者AXF文件的时候，一般既可以把这个文件里面的代码和数据真正地下载到目标板上去，也可以只把其中的调试符号给加载进去。如果目标板上跑的程序是之前就已经烧进Flash里的，或者是在启动的时候被Bootloader搬到了RAM里面，那就一定要把“把程序下载进去”和“只加载符号”这两种情况分得清清楚楚。按照Lauterbach的教程里说的，Data.LOAD这个命令既可以用来把代码和调试符号一起加载，也可以靠着给它加上一个【/NoCODE】的参数，来实现只加载调试符号的效果。

调试环境里如果每次都要手动去点菜单，来做初始化、下载程序、设断点、跑自动化检查这一整套动作，其实是很容易漏掉某个步骤的。想让这些操作自动完成，就要用到TRACE32里的PRACTICE脚本，而很多人比较关心的就是这类脚本到底怎么跑起来，以及万一运行的时候报了错，该从哪些地方下手去查。在动手之前，需要先把脚本的入口在哪、工作目录对不对、参数是不是传全了，还有目标芯片当前的状态，这几件事理清楚，后面会少走很多弯路。按照Lauterbach官方的说明，PRACTICE脚本主要是拿来做自动化配置、自动化测试序列，以及保存系统设置的；在命令行那里，用【DO】命令就可以启动一个PRACTICE脚本，在脚本里面，也照样能用【DO】去调用另一个脚本，一层层配合起来。

Trace32变量看不到，先不要急着怀疑窗口没打开。Lauterbach官方资料里有两个前提说得很清楚，一是TRACE32的HLL调试本身支持优化代码，二是它最终能看到多少变量、多少源码行，仍然取决于编译器给出的调试信息，以及源码和目标代码之间还能不能稳定对应上。也就是说，变量看不到时，排查重点通常不在“TRACE32会不会看变量”，而在“当前构建是不是还保留了足够的调试信息和对象代码映射”。

Trace32抓不到Trace，很多时候不是单纯没点开窗口，而是链路里前面几层没有先对齐。Lauterbach官方资料把典型问题分得很清楚，一类是根本没有有效Trace数据，比如Trace口被别的IO复用、采样建立保持时间不够、目标频率过高；另一类是有数据但带宽不够，结果出现FIFOFULL、FLOWERROR或记录不完整。真正排查时，先把链路有效性和带宽余量拆开看，会比一上来乱改参数更快。

Trace32用SWD连上目标只是第一步，真正能不能用，要看寄存器和内存访问是否稳定。常见现象是刚Up就能看到已连接，但读CPUID读PC时数值乱跳、偶发全零或直接报错，这类问题通常和调试口频率过高、目标处在复位或低功耗状态、以及启动脚本配置不完整有关，按顺序把频率和目标状态先稳住，后面的排查才不会反复绕圈。