4. 量产现场数据采集与问题捕获
量产现场的问题往往具有偶发性、不可复现性和时间窗口极短的特点。当产线测试工位出现异常复位、通信超时或校验失败时，如果只依赖操作员口述"刚才报错了"，几乎无法定位根因。真正有效的做法是：在异常发生的那一刻，由TRACE32自动完成现场冻结、寄存器快照、内存转储和日志同步，把"转瞬即逝"的故障变成"可反复回放"的证据链。本节围绕这套自动采集机制展开，重点讲清楚采集什么、怎么触发、数据如何落地，以及如何判断采集结果是否可信。
一、异常现场需要采集哪些数据
一次完整的现场捕获，至少应覆盖四个层次的信息，它们分别回答不同的问题：
- CPU寄存器快照：PC、LR、SP、xPSR以及通用寄存器R0–R12。PC和LR回答"程序死在哪里、从哪跳过来的"，SP回答"栈是否已经跑飞"，xPSR中的中断号和标志位回答"是否处于异常处理中"。
- 关键外设寄存器：如SCB中的CFSR、HFSR、BFAR、MMFAR，用于判断是硬件错误、总线错误还是用法错误；通信外设的状态寄存器用于判断超时或帧错误。
- 内存转储：至少包含当前栈区、出错任务的控制块、以及被怀疑的数据缓冲区。全片转储代价高，量产环境通常只转储"栈+关键变量区"。
- 同步日志：产线测试脚本输出的工位号、条码、测试项、时间戳，与TRACE32采集时刻对齐，才能把"某块板子"和"某次异常"绑定起来。
这四类数据缺一不可：只有寄存器没有内存，看不到数据被谁改坏；只有内存没有日志，无法回溯是哪块板、哪个工位、哪一步测试触发的。
二、触发方式：从人工中断到自动断点
量产环境不允许操作员手动敲命令，因此触发必须自动化。常见有三种触发源，实际工程中往往组合使用：
- 异常向量断点：在HardFault_Handler、MemManage_Handler等入口设置断点，一旦进入异常立即停下。这是捕获"跑飞"类问题最直接的方式。
- 看门狗/复位标志轮询：上电后先读取复位原因寄存器，若发现是看门狗复位或异常复位，立即触发采集脚本，把上一次运行的残留现场保存下来。
- 测试脚本主动触发：产线测试程序在关键测试项前后调用一个约定的"标记函数"，TRACE32在该函数上设断点，实现"测试步骤—采集时刻"的精确对齐。
需要注意的是，断点触发后系统已经停止运行，此时任何依赖CPU执行的操作（如通过串口打印）都无法进行，因此采集动作必须由TRACE32主机侧完成，而不是目标板侧。
三、采集脚本的组织方式
TRACE32的PRACTICE脚本适合承担这套采集逻辑。一个可用的采集脚本通常包含：变量定义、断点设置、命中后的数据导出、以及文件命名与日志写入。下面给出一个面向Cortex-M的示例框架，参数为教学示例，实际使用时需按芯片手册和工程配置调整：
; 定义采集输出目录与板卡标识
&boardSN="UNKNOWN"
&outDir="C:\trace_capture\"
; 在异常入口设置断点，命中后执行采集
Break.Set HardFault_Handler /Program /CMD "GOTO CaptureNow"
CaptureNow:
; 1. 冻结并读取核心寄存器
Register.view
PRINT "PC=" %HEX Register(PC) " LR=" %HEX Register(LR) " SP=" %HEX Register(SP)
; 2. 读取Cortex-M故障状态寄存器（示例地址，需按手册确认）
Data.Long 0xE000ED28 ; CFSR
Data.Long 0xE000ED2C ; HFSR
Data.Long 0xE000ED38 ; BFAR
; 3. 转储当前栈区（示例范围，按实际SP调整）
Data.Save.Binary "&outDir&boardSN_stack.bin" Register(SP) Register(SP)+0x400
; 4. 转储关键数据缓冲区
Data.Save.Binary "&outDir&boardSN_buf.bin" 0x20001000--0x20001FFF
; 5. 写入同步日志
OPEN #1 "&outDir&boardSN_log.txt" /Create
WRITE #1 "TIME=" SYStime() " PC=" %HEX Register(PC)
CLOSE #1
; 6. 采集完成后停止，等待人工或流程处理
STOP
这段脚本的关键点在于：所有路径和文件名都带板卡标识，避免多板混采时互相覆盖；寄存器读取和内存转储都发生在CPU停止之后，保证数据一致性；日志中写入时间戳，便于与产线MES记录对齐。
四、数据落地与日志同步
采集到的数据如果只留在TRACE32的窗口里，等于没有采集。必须落盘为文件，并建立索引。推荐的做法是：每块板生成一个独立目录，目录名包含条码或工位号，内部固定放置stack.bin、buf.bin、regs.txt、log.txt四类文件。这样后续分析时，只要拿到条码就能定位全部现场数据。
日志同步的核心是"时间对齐"。TRACE32的SYStime()返回的是主机时间，而产线测试脚本记录的是测试系统时间，两者可能存在偏差。工程上通常要求采集脚本在写入日志时同时记录一个由测试脚本传入的"测试序号"，用序号而非绝对时间做关联，可以规避时钟不同步的问题。
五、采集结果的可信度判断
拿到数据后，不能默认它一定有效。至少要做三项检查：
- 栈指针是否在合法范围：如果SP落在RAM区之外，说明栈已经跑飞，此时栈内数据不可信，需要改用其他线索。
- PC是否指向合法代码区：PC落在Flash有效区间内，说明是正常代码路径上的异常；PC为非法值，则更可能是跳转错误或函数指针被破坏。
- CFSR标志位是否与现象一致：例如CFSR的IMPRECISERR置位，说明是总线错误且不精确，此时BFAR可能无效，不能直接采信。
只有这三项检查通过，采集到的寄存器快照和内存转储才具备分析价值。否则应优先怀疑采集时机或采集范围设置不当，而不是急于下结论。