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

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

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

Trace32的会话常被理解为两部分：一部分是调试环境设置，例如工作目录、常用脚本、个人偏好；另一部分是界面窗口布局，例如你打开了哪些窗口、窗口位置和标签页。需要先说明的是，Trace32退出时不会自动帮你记住页面布局，所以要想重启后保持一致，必须显式保存并在下次加载。

在做固件联调或系统Bring-up时，用QEMU先把启动链路跑通很常见，但一旦要接入Trace32做停机调试，最容易卡在两件事：一是连不上或连上后符号对不上，二是能调试但单步慢到影响定位节奏。下面按“先稳定接入，再把单步开销压下去”的顺序，把可执行的配置路径写清楚。

TRACE32抓到的Trace看起来不完整，常见表现是只剩下最后一小段记录、触发点前后的关键片段缺失，或Trace里出现异常标记导致解码中断。要把问题收敛，需要同时确认两件事：一是缓冲区到底以什么方式在写入与覆盖，二是触发条件是否把你想要的时间窗口完整圈住，再往下才是解码与硬件链路层面的校验。

单步调试时一按Step就跑飞，很多时候不是代码真的乱跑，而是调试视角与目标真实执行状态没对上：符号没对齐、指令集状态不一致、中断打断单步、异常直接改写了PC，都会让你看起来像“跳到奇怪地址”。排查要抓住两件事，一是每一步之后PC和SP到底变成了什么，二是异常向量和堆栈是否把CPU引到了错误的入口。

板卡刚上电或脚本刚改完就遇到TRACE32识别不到器件，表面看是JTAG不通，实际上常见分叉点只有两个：一是电气链路不稳定导致TAP进不去稳定状态，二是链路里不止一个TAP但配置仍按单TAP去起调试，最终读不到正确的IDCODE或读到全1全0的假值。建议按由外到内的顺序先把物理链路跑通，再把链路参数与IDCODE对齐，定位会明显更快。