Trace32

调试人员在用TRACE32这个工具看芯片启动的时候，复位操作表面上就是点一下那个【Reset】按钮，或者在控制台敲一个SYStem.Up命令，但是其实里面有很多别的事情在影响最后的结果。大家要是碰到TRACE32复位流程怎么配置，或者TRACE32复位后程序入口跳转异常怎么办这类情况，调试人员不能光看程序最后有没有重新跑起来，还要去检查复位具体是用哪种方式搞的，调试器和板子是怎么连上的，CPU有没有死死停在reset vector这个地方，PC寄存器的初始数值对不对，以及向量表和启动地址到底能不能对得上。

在对嵌入式程序进行调试的时候，TRACE32中变量观察怎么添加，以及TRACE32中变量被优化后看不到该怎么办，这两个问题经常会被大家遇到。表面上看起来这只是变量窗口的使用问题，但是这其实和ELF符号、当前停机的位置、函数的栈帧以及编译优化的等级都有关系。也就是说，并不是只要把变量名输入到TRACE32里面就一定可以显示出数值，调试器还需要知道变量的具体位置，当前代码运行到了哪里，以及这个变量有没有被编译器给保留下来。

在使用TRACE32调试MCU、SoC或嵌入式Linux程序时，很多问题不是程序没有下载进去，而是符号信息没有正确加载。遇到“TRACE32符号文件怎么加载TRACE32符号加载后函数名不显示怎么办”这类情况，需要把程序镜像、ELF调试信息、加载地址、编译选项和TRACE32窗口显示方式一起检查，不能只盯着一个加载命令看。

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

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

在TRACE32调试时，ELF文件不是普通的二进制镜像，它里面通常同时包含代码、数据、符号、源码行号和入口地址等信息。遇到“TRACE32 elf文件怎么加载TRACE32 elf加载地址不对怎么校正”，不能只看Data.LOAD.Elf有没有执行成功，还要看程序是否真的写到了目标内存、符号地址是否和PC对得上、加载的是逻辑地址还是物理地址，以及目标板上的程序是不是和当前ELF属于同一次构建。

在TRACE32里看寄存器，不能只理解成“打开一个窗口读数值”。寄存器显示是否准确，和CPU当前状态、选中的Core、访问权限、调试连接、运行/停机状态都有关系。遇到“TRACE32寄存器窗口怎么查看TRACE32寄存器值刷新异常怎么判断”，建议先确认窗口显示的是哪类寄存器，再判断这个值是在停机态读到的，还是在目标运行过程中动态刷新出来的。

在芯片调试的初期阶段，技术人员经常需要进行目标板bring-up以及底层驱动调试，或者进行多核芯片联调，此时经常会遇到TRACE32目标板连接如何配置，以及TRACE32连接后CPU停不下来怎么办这两个具体问题，并且这两个问题常常同时出现。在实际排查时，这两个现象通常都和芯片型号的挑选、调试接口的选择、复位链路的连通、JTAG时钟的快慢、多核环境的配置以及目标板的硬件状态产生交织。因为TRACE32本身支持的芯片类型和架构非常多，所以Lauterbach公司提供了很多配置好的启动脚本，这些脚本可以帮助技术人员减少手工配置时犯错的概率。

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

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

在 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的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、接着设置芯片相关选项、最后建立通信。