Trace32

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

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

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

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

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

程序跑起来以后，变量窗口里的数值一直没有变化，很容易让人以为是代码逻辑根本没有被执行。关于TRACE32变量监视怎么添加，TRACE32变量值刷新异常怎么处理，得先区分出两种情形：一种是在程序暂停下来时去查看变量，另一种是让程序在运行过程中持续刷新。TRACE32提供了Var.View、Var.Watch这些功能，也具备运行时访问内存的能力；但是芯片的架构、缓存、MMU还有调试时的配置，全都会影响最终显示的结果。Lauterbach的文档也说明，程序运行期间能不能直接读写内存，要看目标处理器是否支持对应的访问方式。

调试器能成功连上芯片，并不代表就能把数据稳稳当当地写进Flash里。在TRACE32环境下，Flash烧录要怎么配置，以及烧录过程中如果Flash算法加载失败了又该怎么去排查，关键是把几个方面对应好：目标芯片的连接是不是稳定、Flash的地址范围有没有写对、算法运行时占用的那一段RAM有没有冲突、时钟和总线的配置是不是正确，还有要烧进去的那个文件它的格式和装载地址能不能匹配上。根据Lauterbach的资料，TRACE32支持通过内存映射的方式来编程Flash，它既提供了现成的脚本和编程算法，也可以直接用命令或者脚本来执行烧录操作。

Trace32 Flash脚本怎么写，先不要把重点放在“命令越多越完整”。Lauterbach官方资料里，真正稳定的Flash流程通常就三段，先连目标并准备Flash驱动，再进入重编程模式装载镜像，最后退出重编程模式并重新装入符号。官方示例里已经给出了这条主线，而且也明确说明PRACTICE脚本就是TRACE32用来做自动化的标准脚本形式，扩展名是.cmm。

很多人用TRACE32调试时，程序已经跑起来了，真正卡住的却是符号这一步。最典型的现象就是函数名不显示、源码打不开、变量看不到，或者明明加载过文件，地址和符号还是对不上。Lauterbach官方文档把这件事分得很清楚，TRACE32里的Data.LOAD不只是“把文件读进来”，它同时会处理代码、寄存器、符号和调试信息；如果你用了错误的文件类型、没处理好地址偏移、路径映射或多份符号共存，最后看起来就会像“符号加载失败”。

做TRACE32授权这件事，第一步不是先找激活按钮，而是先分清你手里到底是哪一类授权。Lauterbach官方公开资料里，TRACE32常见授权大体分成两条线，一条是跟硬件调试器走的调试线缆和功能密钥，另一条是给软件形态使用的浮动许可，也就是通过RLM服务器发放给客户端。两条线的激活方式、迁移方式和离线处理方法并不一样，搞混以后最容易在换电脑、换服务器和断网使用时出问题。

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

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

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

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

Trace32变量看不到，先不要急着怀疑窗口没打开。Lauterbach官方资料里有两个前提说得很清楚，一是TRACE32的HLL调试本身支持优化代码，二是它最终能看到多少变量、多少源码行，仍然取决于编译器给出的调试信息，以及源码和目标代码之间还能不能稳定对应上。也就是说，变量看不到时，排查重点通常不在“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做追踪，常见情况不是功能找不到，而是窗口开出来以后不知道先配哪一步。有人一上来就急着下触发条件，结果缓冲区太小，抓到的全是零散片段；也有人先开了Trace，却没把采集来源和记录范围收住，最后列表里数据很多，真正有用的内容反而看不出来。要把这件事做顺，思路不能乱，先把Trace链路配通，再去定缓冲区和触发条件，排查时才不会一层套一层。

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