1. 课程导入与TRACE32环境搭建
ARM异常与崩溃分析，是嵌入式底层开发中最考验“证据链”能力的一类工作。当系统跑飞、HardFault、数据异常、任务卡死时，仅靠打印日志往往无法还原现场：栈被破坏、寄存器被覆盖、异常嵌套发生后，日志本身也可能失真。TRACE32（Lauterbach）提供的是一套“非侵入式观察 + 现场冻结 + 回溯分析”的能力：它可以在CPU异常入口处停下，读取R0–R15、xPSR、CFSR、HFSR、BFAR、MMFAR等关键寄存器，查看异常发生前后的调用栈、反汇编与内存，从而把“崩溃”从现象变成可定位的因果链。
本课程的目标不是泛泛介绍调试器，而是围绕ARM Cortex-M/A系列的异常模型，建立一套可复现的分析方法：从环境搭建、目标连接、符号加载，到异常向量捕获、栈帧回溯、故障寄存器判读，再到多任务/RTOS场景下的崩溃定位。第1章先完成两件事：理解异常分析的核心价值，并搭建一个能稳定复现调试会话的TRACE32环境。
1.1 为什么异常分析必须依赖调试器
以Cortex-M为例，当发生HardFault时，内核会自动将部分寄存器压入当前栈（异常压栈帧），包括R0、R1、R2、R3、R12、LR、PC、xPSR。若使能了浮点，还可能压入S0–S15等。这个压栈帧是“第一现场”，但很多开发者只看到PC指向HardFault_Handler，就误以为问题在异常处理函数里。实际上，真正触发异常的指令地址、访问的非法地址、总线错误类型，分别藏在压栈PC、BFAR/MMFAR、CFSR等位置。没有调试器，这些信息很难完整获取；有了TRACE32，可以在异常入口设置断点，冻结现场后逐项读取。
更关键的是，TRACE32支持在异常发生前设置“数据访问断点”或“总线错误捕获”，把问题从“崩溃后猜测”前移到“非法访问发生时立即停下”。这对定位空指针、野指针、栈溢出、外设寄存器误写、MPU违规等典型问题非常有效。
1.2 TRACE32软件安装与授权准备
TRACE32的安装包通常按架构和调试接口区分，例如PowerView for ARM、TRACE32 ICD（In-Circuit Debugger）等。安装时建议注意三点：第一，安装路径不要包含中文和空格，避免脚本和配置文件解析异常；第二，确认License文件与所用调试器型号匹配，若使用QEMU或SIMulator，需要确认授权是否覆盖对应功能；第三，安装完成后检查t32可执行文件、config.t32配置文件以及demo示例目录是否完整。
一个典型的config.t32片段如下，用于指定调试器与目标接口：
PBI=
USB
DEVICE=ICD
CHANNEL=1
PACKLEN=1024
SCREEN=
HEADER=Trace32
WIDTH=1024
HEIGHT=768
FONT=SYSTEM
若使用QEMU，则通常通过TRACE32的“QEMU”或“SIM”后端连接，配置中会指定QEMU的GDB端口或共享内存路径。实际配置应以所用TRACE32版本和QEMU集成方式为准。
1.3 连接ARM调试目标：硬件仿真器与QEMU两条路径
硬件路径下，常见连接是TRACE32 ICD通过JTAG/SWD连接目标板。以SWD为例，需要确认：目标板供电正常、SWDIO/SWCLK/GND连接可靠、复位引脚可选连接、目标芯片的调试接口未被禁用（例如某些芯片的SWD引脚被复用为GPIO后需要先解锁）。连接后，在TRACE32中执行SYStem.CPU选择正确内核，例如SYStem.CPU CortexM4，再执行SYStem.Up使目标进入调试状态。
QEMU路径更适合没有硬件的学习场景。典型做法是启动QEMU并开启GDB stub，例如：
qemu-system-arm -M lm3s6965evb -kernel firmware.elf -S -gdb tcp::3333
然后在TRACE32中通过SYStem.CONFIG或QEMU后端连接该端口。连接成功后，TRACE32应能读取到PC、SP和内核寄存器，说明调试通道已建立。
1.4 第一个调试会话：加载符号、设置异常断点、读取现场
连接目标后，第一步是加载ELF文件，让TRACE32获得符号、段地址和源码路径：
Data.LOAD.Elf firmware.elf /NoClear
随后设置异常入口断点。以Cortex-M的HardFault为例，可以先查看向量表地址，再在HardFault_Handler处下断：
Break.Set HardFault_Handler /Program
Go
当程序命中HardFault后，不要急着单步。先读取异常压栈帧。若当前SP为MSP，且异常发生时使用MSP，则压栈帧通常位于MSP指向的位置。TRACE32中可用Register.View查看R0–R15、xPSR、CFSR、HFSR、BFAR、MMFAR。重点判读：CFSR的IMPRECISERR、PRECISERR、IBUSERR、UNALIGNED、DIVBYZERO等位；若BFAR有效，则BFAR给出非法访问地址；若MMFAR有效，则给出MPU违规地址。压栈PC则指向触发异常的指令附近。
下面这张图给出从“连接目标”到“读取异常现场”的关键信号链与判读路径，帮助建立整体操作框架：
1.5 环境搭建中的常见问题与判断依据
连接失败时，先区分“调试器未识别”与“目标未响应”。若TRACE32提示无法打开调试器，检查USB驱动、License和config.t32中的PBI配置；若调试器已识别但SYStem.Up失败，检查目标供电、复位状态、SWD引脚复用和内核选择是否正确。QEMU场景下，若连接后PC为0或寄存器不可读，通常是QEMU未真正停在GDB stub，或ELF加载地址与QEMU加载地址不一致。
一个可复现的验证标准是：连接后能读到合理的PC（位于Flash或RAM代码区）、SP指向有效栈区、加载ELF后能在源码窗口看到函数名。达到这三点，说明第一个调试会话已经建立，后续的异常捕获才有可靠基础。