普通断点只能观察程序停止时的状态，硬件跟踪则可以连续记录分支跳转、函数调用、中断和任务切换，更适合排查偶发死机、执行路径异常以及实时性下降。围绕“TRACE32硬件跟踪怎么使用TRACE32跟踪数据不完整是什么原因”，配置时要先确认芯片提供的跟踪模块，再根据片上缓冲区或外部跟踪设备选择采集方式。

在调试程序执行路径、函数调用顺序、异常前后现场时，经常会用到TRACE32的trace记录。遇到“TRACE32 trace记录怎么开启TRACE32 trace记录为空怎么排查”，不能只看有没有点【Go】。Trace记录是否有内容，和芯片是否支持trace、TRACE32选择的trace method、缓冲区是否初始化、AutoArm是否开启、触发条件和过滤范围是否设置正确都有关系。简单说，trace不是普通断点窗口，它需要先有“数据来源”，再有“记录配置”，最后才有“显示结果”。

在进行TRACE32调试的时候，断点并不是随便点一下就可以的，因为断点的位置、符号文件、代码运行的区域，还有优化等级以及变量所在的作用域，这些因素都会对后面的调试结果产生影响；当遇到断点设置和变量查看的问题时，作者建议把这两者放在同一个流程里去排查，也就是去检查断点能不能设置成功、程序能不能停下来、停下来之后具体在哪个地方、当前的栈帧是否正确，以及变量是不是被编译器优化掉了。

板卡刚上电进行调试的时候，如果启动脚本的先后顺序编排得不怎么稳当，经常会表现出来的现象包括：连接一会儿好一会儿坏，芯片复位之后程序自己跑飞掉，或者明明符号已经加载成功了，可断点就是打不进去。关于TRACE32的启动脚本该如何去编排，以及上电以后的初始化顺序怎样去确认，比较合理的做法是把一整段PRACTICE脚本拆分成连接、目标初始化、程序加载、调试配置跟运行控制这么几个部分。TRACE32里头的PRACTICE脚本，它的主要用处是拿来做自动配置、测试自动化，还有把系统设置给保存下来，这类脚本一般都会存成.cmm文件，既可以在命令行下用DO命令直接去跑，也能够让别的脚本去调用它。

在嵌入式系统的调试、查看时间先后关系，还有让异常再次出现以及检查代码覆盖情况的阶段，有两个问题经常碰到：TRACE32的Trace窗口要怎么看，另外就是Trace数据被弄丢了通常都跟哪些情况有关系。先要弄明白的是，Trace跟我们平时说的那种日志不一样，它记下来的东西是目标设备在跑的时候生成的程序走向、对数据做读写的动作、时间点标记，还有各种系统里发生的事件。按照Lauterbach那套教程里讲到的，TRACE32可以把Trace记录下来，再通过专门的窗口去展示和分析；而AURIX的培训材料里头也提到了，通过Trace是能够把完整的程序流给展现出来的。

在实际调试中，TRACE32的JTAG速度怎么设定，以及连接时钟拉得太高会带来什么问题，这两个情况现场经常碰到。JTAG速度，本质上就是调试器跟目标芯片之间那根TCK时钟线上的频率；把频率调高一些，下载程序、读写内存和刷新变量这些操作确实能变快，可当板子上信号质量不够好、芯片上电后状态还不稳定、调试接口设计本身有缺陷，或者目标器件内部的时钟跟不上时，速度开得太高反而会让连接失败。在Lauterbach的调试会话教程里，也有这样的顺序：先选CPU、再按需要调整JTAG clock、接着设置芯片相关选项、最后建立通信。

Trace32连JTAG时，很多问题表面看像是软件命令没输对，实际更常见的是物理连线、调试口类型、JTAG链长度和时钟余量没先对齐。Lauterbach的官方资料已经把这条线说得很清楚，TRACE32支持标准JTAG、cJTAG和SWD，不同接口要在系统配置里选对；而链路稳定性又和TCK时钟、TMS、TDI、TDO的时序余量直接相关，时钟一旦拉得过高，就很容易出现探测得到IDCODE却进不了内核、或者直接报debug port fail的情况。

很多人第一次用Trace32做追踪，常见情况不是功能找不到，而是窗口开出来以后不知道先配哪一步。有人一上来就急着下触发条件，结果缓冲区太小，抓到的全是零散片段；也有人先开了Trace，却没把采集来源和记录范围收住，最后列表里数据很多，真正有用的内容反而看不出来。要把这件事做顺，思路不能乱，先把Trace链路配通，再去定缓冲区和触发条件，排查时才不会一层套一层。

Trace32里把目标CPU选对，只是把调试器的协议和寄存器定义对上，并不等于核心一定能被识别出来。很多现场的问题是CPU型号已经选了，SYStem也能点Up，但状态栏还是No CPU或core inactive，寄存器读不到或只能读到一部分。处理这类情况，建议先把CPU选择入口走完整，再按链路识别、多核分配、目标调试权限这三条线逐步排查。

用Python控制Trace32，核心是把Trace32远程控制通道先打开，再让Python通过远程接口发命令并读取回执。很多人遇到的所谓权限不足，其实更像命令被锁定，原因通常是系统状态不对，例如还没【SYStem】→【Up】就去下断点，或目标处在不支持该命令的上下文里；先按可复现的链路把远程通道和状态拉齐，再处理报错会更快收敛。