嵌入式程序在运行时偶尔跑飞、任务切换出现异常，或者中断的时序表现得不稳定，这种时候光靠设置断点来一点一点地追，往往很难把问题复现出来，所以就需要搞清楚Green Hills的Trace功能是怎么把运行信息给采集上来的，以及万一Trace记录不完整，又该从哪些方面去排查，这通常要结合MULTI调试器、TimeMachine回溯工具还有硬件Trace探针这几样东西一起来看才行。Green Hills的TimeMachine可以自动把程序实际执行的数据给捕获下来，然后让调试器能够往前或往后去分析程序跑起来的过程，而Green Hills Probe V4这类的探针也提供了高速的Trace存储空间和足够的带宽，专门用来采集程序运行当中的跟踪数据。

　　一、Green Hills Trace怎么采集运行信息

　　在动手采集Trace之前，先要确认目标芯片、调试探针以及整个工程的配置，都支持Trace功能，并不是所有的目标板都能把完整的指令流给录下来，也不是所有的调试连接都带着Trace这条通道。

　　1、确认硬件连接是否就绪

　　先把Green Hills Probe或者SuperTrace Probe正确地连到目标板上，把JTAG、Trace接口、目标板的供电还有时钟都检查好，保证这些东西工作正常；像Probe V4这种型号，本身就带了4GB的高速Trace内存和40Gbits每秒的聚合带宽，很适合用来做长时间和高频率的数据采集，所以在硬件这边，空间和速度是有保障的。

　　2、把目标连接配置好

　　接着打开MULTI连接配置的界面，在里面选好对应的目标芯片和调试器的类型，如果用的是SuperTrace Probe，还得把探针的连接方式、IP地址或者主机名都填写进去；按照Renesas相关配置资料里的说明，SuperTrace Probe会跟已有的调试连接配合在一起，专门去抓取目标运行过程中产生的Trace数据。

　　3、启动TimeMachine的Trace功能

　　进到MULTI调试器以后，去打开跟TimeMachine有关的菜单，从中选好Trace或者Trace List这一项，就能看到程序的运行记录了；在NXP的Green Hills工具练习资料里面也提到过，可以在Debugger窗口的Time Machine菜单里打开Trace List，并通过这个列表去查看函数级别以及汇编级别的Trace信息。

　　4、把采集的范围定下来

　　在正式开始采集以前，先确定好这次重点想抓的是任务切换的瞬间、中断的进入和退出、某些函数调用过程，还是程序异常发生前后的那一段；为了不让Trace缓冲区很快被一堆无关的大循环和空闲任务给塞满，可以借助断点、触发条件或者截取一小段时间窗口的方式，把范围收缩到紧扣问题的地方。

　　二、Green Hills Trace记录不完整怎么排查

　　Trace记录不完整，常见的现象有前头一段数据丢了、某个关键的调用压根儿没有出现在列表里、记录中途突然断掉，又或者是只能看到很短的一小段执行过程，在排查的时候，一般先从Trace的来源和缓冲区的状况下手，然后再去看触发条件是不是设得有问题。

　　1、检查Trace缓冲区有没有溢出

　　如果程序跑的时间太长、指令流太密，或者采集的范围开得过宽，都会让缓冲区很快就写满了，即便是Probe V4这种带较大Trace内存的探针，长时间做全量记录，早期抓到的数据也仍然可能被后面不断涌进来的新数据给覆盖掉；所以可以试着把采集的窗口缩短一些，只抓问题发生前后那几秒钟的数据，反而更容易留下完整的记录。

　　2、重新审视触发条件

　　如果事先设了Start Trigger、Stop Trigger，或者指定只在某些函数范围内触发，那么条件写得过窄的时候，可能从头到尾都根本没有触发过采集，而条件过宽时，又会在真正需要观察的点之前就提前停止了；可以先用一组最简单的条件，确认Trace能够正常启停，再逐层把复杂的过滤规则加上去，这样判断起来更清晰。

　　3、检查优化等级和符号信息

　　当函数级别的Trace看起来缺头少尾的时候，有时候并不是Trace本身丢数据，而是编译优化、函数内联或者符号文件没有完全匹配造成的；这时可以考虑用一版带完整调试信息的构建结果去复测，确认源代码、ELF文件跟当前烧进板子里的程序是严格一致的，这样符号解析才靠得住。

　　4、确认目标是不是进了低功耗或者被复位

　　目标板发生复位、看门狗突然咬合、或者芯片进入了低功耗模式把Trace时钟给关掉，这些都会让记录戛然而止；如果发现Trace总是在某个时间点突然停下来，就要同步去查看目标芯片的复位原因寄存器、看门狗的状态，还有电源相关的日志，往往能从中找到真正打断记录的那只手。

　　三、Green Hills Trace结果怎么复核

　　当Trace数据全都采集下来之后，不要只盯着列表最后那几行，真正派得上用场的是把异常发生前的函数调用链、任务切换顺序还有关键数据读写的先后过程串在一起看。

　　1、从异常点倒着往回看

　　可以借助TimeMachine的功能，从发生异常的那个位置开始，朝前面倒着去翻，找一找在这之前最近的一次关键变量写入、任务切换或者中断进入是什么时候；TimeMachine最有价值的地方，恰好就在于它能基于已经捕获的执行数据，灵活地向前和向后调试，比单靠断点要直观很多。

　　2、把源码和汇编对照着分析

　　函数级的Trace适合拿来看整体流程，汇编级的Trace则在查精确跳转和异常入口的时候更有用，这两种视图要结合起来看，尤其是在编译器打开优化以后，源码里每一行对应的指令顺序可能已经变了，只看源码容易跟丢实际执行的路线。

　　3、把这次采集的配置保存下来

　　采完之后，顺手把探针型号、连接方式、Trace的触发条件、工件的版本、ELF文件还有采集的时间点都记在一起，等到后面再次碰到类似问题，就可以直接把配置复用起来，不需要再从头摸索一遍，也方便在团队内部做交接和复盘。

　　总结

　　要用Green Hills Trace采集运行信息，最开始得先保证目标芯片和探针都支持Trace功能，再进到MULTI和TimeMachine里面，把采集的范围、触发条件和Trace List的查看方式给配置好；等拿到Trace之后，如果发现记录不完整，就要重点排查是不是缓冲区被覆盖了、触发条件写得不合适、符号匹配有问题，或者目标中途发生了复位和进入低功耗；最后，在复核的时候，要把Trace数据跟源码、汇编以及异常时间点放在一起互相印证，这样才能真正把程序运行中的关键问题给揪出来。