Trace32

TRACE32通常使用PRACTICE脚本保存处理器选择、调试接口、程序装载和断点等操作，文件一般使用.cmm扩展名。工程换目录、升级TRACE32后，如果脚本不再自动执行或运行到中间停止，可以先确认脚本有没有被调用，再检查路径、命令和目标板状态。

使用TRACE32烧写Flash，连接成功只是起点，芯片脚本、Flash地址、目标RAM、看门狗、缓存和程序文件还要逐项匹配。下面围绕“TRACE32怎么烧写Flash程序TRACE32烧写Flash失败如何检查配置”展开，直接按照实际操作顺序说明烧写与排查方法。

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

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

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

TRACE32里的“调试日志”可能指PowerView命令记录、系统访问日志、变量变化记录，也可能是Trace采集结果。不同日志使用的导出命令并不一样。需要保留调试过程时，可以使用【LOG.OPEN】记录TRACE32操作；要分析目标访问异常，则更适合查看【SYStem.LOG.List】；如果准备把某个窗口内容保存成文本，还可以通过【PRinTer.FILE】和【WinPrint】导出。日志生成后内容不完整时，要先确认记录对象和启动时间，再检查输出范围、文件覆盖以及目标访问是否真的被纳入记录。

TRACE32能够连接芯片、加载程序并查看源码，并不等于它已经识别RTOS中的任务和内核对象。操作系统感知还要加载匹配的扩展，并依赖完整符号与可读取的内核数据。围绕“TRACE32操作系统感知怎么开启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在调试FreeRTOS、AUTOSAR OS、Linux以及其他受支持操作系统时，可以通过OS Awareness读取内核中的任务控制信息，并显示任务名称、状态、优先级、当前运行核心等内容。打开任务列表后只看到部分任务、任务名称为空、状态栏出现task error，或者某些任务字段缺失时，应先确认OS Awareness已经加载，再检查内核符号、地址转换和操作系统初始化状态。

TRACE32配置多核调试时，核心数量并不是唯一依据。各核心是否运行同一操作系统、是否需要独立启停、是否共享地址空间，都会影响调试模式。处理“TRACE32怎么配置多核调试TRACE32多核同步调试异常如何排查”时，应先确定SMP或AMP，再配置核心编号、实例通信和同步动作，后续异常才容易定位。

在 TRACE32 调试时，内存窗口不仅能看 RAM、外设寄存器、栈区和全局变量区，有些场景下也可以直接改内存内容。遇到“TRACE32内存窗口怎么修改 TRACE32内存写入失败怎么处理”，不要只理解成窗口里改不了数值。它背后可能涉及 CPU 是否停机、地址是不是有效 RAM、访问宽度是否正确、当前 access class 是否匹配、目标芯片是否开启了写保护，以及写入区域到底是 RAM、Flash 还是外设寄存器。

在对多核心芯片进行调试的时候，调试人员不能简单地认为只要连上一个内核再点击运行就可以了；调试人员首先需要明确当前芯片到底是使用的SMP模式、AMP模式，还是混合多核心的办法在运行；如果调试人员把模式选错了，在后续的过程中，就容易碰到某个内核停下来了而另一个内核还在继续跑的现象，或者断点明明被触发了，但是窗口里面显示出来的却不是调试人员想要看的那个目标核心。

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

TRACE32支持给程序断点、内存访问断点增加逻辑条件，只有CPU命中断点位置并且条件成立时才保持停止。调试循环变量、状态机、错误计数或指定寄存器值时，条件断点比反复手工继续运行更方便。条件已经配置却始终不停，通常要检查表达式类型、变量当前是否可访问、断点地址是否真正命中，以及目标芯片还能不能提供对应的硬件断点资源。

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

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

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

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