📚 课程目录第3章 TRACE32调试基础与崩溃现场捕获

3. TRACE32调试基础与崩溃现场捕获

在ARM异常与崩溃分析中，TRACE32的价值不只是“能连上目标板”，而是能够在异常发生的第一时间冻结CPU、保留现场，并把ELF符号、寄存器、内存和栈回溯串成一条可解释的证据链。本节围绕这条证据链展开：如何加载ELF、如何设置断点、如何单步、如何查看寄存器和内存，以及崩溃发生时如何冻结CPU并保存现场。

一、加载ELF：让地址变成符号

TRACE32通过调试器（如PowerDebug、ICD或TRACE32 Probe）与目标芯片的JTAG/SWD接口连接。连接后，第一步不是急着下断点，而是加载ELF文件。ELF中保存了代码段、数据段、符号表、调试信息（DWARF）和行号信息，TRACE32据此把裸地址翻译成函数名、变量名和源码行。

典型命令如下：

SYStem.CPU CortexA9
SYStem.JtagClock 10MHz
SYStem.Up
Data.LOAD.Elf app.elf /NoClear
Data.LOAD.Elf app.elf /NoClear /SourcePATH .

其中 SYStem.Up 让调试器接管CPU；Data.LOAD.Elf 把ELF的代码、数据和符号载入TRACE32的调试数据库。若目标程序已由BootROM或烧录工具写入Flash，则使用 /NoClear 避免清空内存，仅加载符号。加载完成后，用 List.Mix 或 List.auto 可以看到C源码与汇编交错显示，这是后续定位崩溃点的基准视图。

若ELF与目标实际运行的镜像不一致（例如编译时间不同、链接地址不同），符号会错位，断点可能落在错误地址。加载前应确认ELF的构建版本与目标镜像一致。

二、断点与单步：控制执行流

TRACE32支持软件断点和硬件断点。软件断点通过替换指令实现，数量多但会修改内存；硬件断点由CPU调试单元实现，数量有限（通常2~6个）但不改内存，适合在Flash或只读代码中设置。

Break.Set main /Program
Break.Set 0x80001234 /Program /Hardware
Break.List
Break.Delete

设置断点后，用 Go 运行，命中后CPU停止。此时可用 Step 单步进入函数，Step.Over 单步跳过函数，Step.Return 执行到当前函数返回。单步时观察 Register 窗口和 Frame 窗口，可以判断执行流是否偏离预期。

对于崩溃分析，断点策略通常分两层：一是在异常向量入口（如 0x00000008 的Data Abort、0x0000000C 的Prefetch Abort）设置硬件断点，确保异常一发生就停住；二是在可疑函数入口设置软件断点，用于缩小问题范围。

三、查看寄存器与内存：读取现场

CPU被冻结后，寄存器就是最直接的现场。TRACE32的 Register 窗口显示R0~R15、CPSR、SPSR以及协处理器寄存器。ARM异常分析中，重点看：

PC：异常发生时的指令地址，结合 List.Mix 可定位到具体源码行。
LR：返回地址，用于判断调用来源。
SP：栈指针，用于栈回溯。
CPSR：模式位（M[4:0]）、中断屏蔽位（I/F）、条件标志（N/Z/C/V），可判断异常发生时的处理器状态。
DFSR/DFAR、IFSR/IFAR：数据/指令异常的状态与地址寄存器，直接说明访问了哪个非法地址、属于何种异常。

内存查看使用 Data.dump 或 Data.List：

Data.dump 0x80000000
Data.dump 0x80000000 /Long
Data.List 0x80001000

结合符号，可以用 Data.dump &variable 直接查看变量内容。若怀疑栈被破坏，用 Data.dump SP 查看栈顶若干字，再配合 Frame 窗口做栈回溯。

四、崩溃现场捕获：冻结CPU并保存

崩溃现场捕获的关键是“先冻结，再保存，后分析”。当异常发生或程序跑飞时，TRACE32可以通过 Break 命令立即停止CPU，或用 SYStem.Mode Down 断开调试连接但保留内存内容。更稳妥的做法是：在异常向量入口设置硬件断点，命中后CPU自动停止，此时不要立即复位或重新加载程序，而是先保存现场。

保存现场包括三部分：寄存器快照、内存快照和栈回溯。TRACE32提供 Register.Save、Data.SAVE 等命令，也可以使用 PRINT 或 AREA 导出文本。

Register.Save reg_snapshot.txt
Data.SAVE.Binary mem_snapshot.bin 0x80000000--0x800FFFFF
Frame.View /Locals /Caller

保存后，用 Frame.View 查看调用栈，用 List.Mix 对照PC附近的汇编，用 Data.dump 检查DFAR指向的地址是否合法。若DFAR指向 0x00000000 或 0xFFFFFFF0，通常说明空指针或非法指针访问；若DFSR显示对齐错误，则检查访问宽度和地址对齐。

冻结CPU后，不要急于执行 Go 或 Reset，否则寄存器、栈和内存可能被覆盖，现场丢失。应先保存快照，再决定是否复位。

五、现场捕获的完整判断路径

下面这张图把“加载ELF—断点—冻结—保存—判读”串成一条现场捕获链路，并标出每一步的关键命令与观察对象。图中同时给出异常入口断点、寄存器判读和内存快照的对应关系，便于在实际调试时按图操作。

实际调试时，建议把上述命令整理成一个现场捕获脚本，命中异常断点后一键执行，避免手工输入遗漏。例如：

PRINT "=== Register Snapshot ==="
Register
PRINT "=== DFAR/DFSR ==="
Register.RTView DFAR
Register.RTView DFSR
PRINT "=== Stack ==="
Frame.View /Locals /Caller
PRINT "=== Memory at DFAR ==="
Data.dump DFAR

脚本执行后，把输出保存为文本文件，与ELF、map文件一起归档。这样即使目标板需要复位继续运行，崩溃现场仍然可复查。对于偶发崩溃，还可以结合TRACE32的Trace功能（如ETM/ETB）记录异常前的指令流，但Trace配置属于后续章节内容，本节先把“冻结—保存—判读”这条基础链路走通。

最后强调一个常见误区：很多初学者在异常断点命中后，习惯性地按 Go 继续运行，结果寄存器被后续代码覆盖，DFAR/DFSR也可能被新的异常改写。正确顺序永远是：命中→冻结→保存→判读→再决定是否复位。只有把现场完整保留下来，后续的栈回溯、内存比对和根因分析才有可靠依据。