一次“预取中止”引发的深度追查：如何在ARM7上揪出未映射内存访问
你有没有遇到过这种情况——系统上电后毫无征兆地卡死，连串口都来不及吐出一个字节？或者固件升级之后，板子再也启动不起来，JTAG也连不上？更离谱的是，某些功能偶尔崩溃，但复现无规律，像是被“诅咒”了一样。
如果你正在用ARM7系列处理器（比如LPC21xx、AT91SAM7这类经典芯片），那很可能，问题就藏在一个不起眼的异常里： 预取中止（Prefetch Abort） 。
这玩意儿听起来挺学术，但它其实是嵌入式开发中最值得掌握的“现场取证”技能之一。尤其是在没有调试器、没有操作系统、甚至连堆栈都没初始化的裸机环境下，它几乎是唯一能告诉你“刚才到底发生了什么”的线索。
预取中止不是Bug，是CPU在报警
我们先来打个比方：
想象你在图书馆找一本书，管理员告诉你：“这本书在3楼东区第5排。”你兴冲冲跑过去，结果发现那里根本没书架——空荡荡的一面墙。
这时候你会怎么做？当然是回头问管理员：“你说的位置不对啊！”
ARM7的预取中止机制，干的就是这个事。
当CPU准备执行下一条指令时，它会去内存地址“取指”。如果那个地址压根就不该存在（比如超出了Flash范围、RAM边界外、或者某个外设区域没使能），硬件就会说：“等等，这片区域我不能让你读！”然后拉高
nABORT
信号线。
CPU一检测到这个信号，立刻停下脚步，切换到
Abort模式
，保存现场，并跳转到异常向量表中的
0x0000000C
位置——也就是预取中止的入口。
🧠 所以说，预取中止不是程序写错了才出现的问题；相反，它是系统 正常工作的表现 ——说明硬件保护机制起了作用，阻止了灾难性的非法操作继续蔓延。
可惜的是，很多开发者把异常处理函数留空，或者只放了个无限循环：
void PrefetchAbortHandler(void) {
while(1); // 啥也不做
}
这就等于警察赶到案发现场，看到满地血迹，却转身走了……下次还出事，照样抓不到元凶。
异常发生时，CPU到底记住了什么？
关键就在于几个寄存器的状态。别小看这几行数据，它们就是破案的关键证据链。
1.
LR_abt
：最后一个已知的“安全点”
当预取中止触发时，ARM7会自动把返回地址存入
R14_abt
（即Abort模式下的LR）。这个值等于
发生异常时PC减去4
。
为什么是PC-4？
因为ARM采用三级流水线结构：
- PC指向当前要取的指令
- PC-4是指令译码阶段的地址
- PC-8是正在执行的指令地址
所以当CPU试图从A地址取指失败时，实际“想执行”的那条指令是在
PC - 8
处，而
LR_abt = PC - 4
刚好指向下一条待执行的指令。
换句话说，
LR_abt + 4
大致就是导致异常的那条“致命跳转”所在的地址。
举个例子：
LDR PC, =BadAddr ; 假设这条指令位于 0x0000_1238
NOP ; 位于 0x0000_123C
如果
BadAddr
是
0x0009_0000
（超出映射范围），那么：
-
CPU尝试从
0x0009_0000取指 → 失败 - 触发预取中止
-
LR_abt被设置为0x0000_123C（即PC-4） -
因此，异常地址 ≈
LR_abt + 4 = 0x0000_1240？不对！
等等，这里有个陷阱！
实际上，在执行
LDR PC,=BadAddr
这条指令时，PC已经指向
0x0000_123C
（ARM流水线特性），所以真正出问题的指令地址是
LR_abt - 4 = 0x0000_1238
。
✅ 正确公式应为：
故障指令地址 ≈ LR_abt - 4
这个细节非常重要。如果你直接拿
LR_abt
去反汇编，可能会错判成下一条指令，从而误入歧途。
2.
SPSR_abt
：异常前的“精神状态”
SPSR_abt
保存的是进入异常之前的CPSR内容，包括：
- 当前处理器模式（User? IRQ? SVC?）
- 中断使能标志（I/F位）
- 条件标志（N/Z/C/V）
这些信息可以帮助你判断：
- 是在中断服务程序里跳飞的？
- 还是在用户任务中调用了野函数指针？
- 或者系统已经被严重破坏，模式都乱套了？
比如，如果你发现
SPSR_abt
显示当时处于Undefined模式，那就说明之前已经有另一个异常没处理好，现在属于“二次事故”。
3.
FAR
和
FSR
：协处理器里的“黑匣子”
这两个寄存器位于CP15（协处理器15），通过MRC/MCR指令访问：
MRC p15, 0, R0, c6, c0, 0 ; 读 FAR —— 故障虚拟地址
MRC p15, 0, R1, c5, c0, 0 ; 读 FSR —— 故障状态码
但注意⚠️：根据ARMv4T架构规范， 预取中止并不会自动更新FAR ！只有数据中止才会强制写入FAR。
这意味着，如果你在预取中止处理函数里读FAR，得到的可能是上次数据中止遗留下来的脏数据！
😱 听起来很危险对吧？
所以最佳实践是：在每次进入预取中止处理函数时，先主动清零FAR：
MOV R0, #0
MCR p15, 0, R0, c6, c0, 0 ; 清除 FAR
这样后续若发生数据中止，才能确保FAR记录的是最新错误地址。
至于FSR，它提供了一个编码值，告诉你具体是什么类型的访问失败。常见值有：
| FSR值 | 二进制 | 含义 |
|---|---|---|
| 0x08 | 0b1000 | 指令预取中止（外部中止） |
| 0x0C | 0b1100 | 数据中止：段缺失 |
| 0x15 | 0b10101 | 权限不足（用户模式访问内核页） |
虽然预取中止的FSR通常是
0x08
或
0x0E
，但它至少能帮你确认是不是真的“取指失败”，而不是别的异常伪装过来的。
实战案例：一次固件升级后的神秘死亡
让我讲个真实的故事。
某客户反馈：新版本固件烧录后，板子完全无法启动，电源灯亮，但没有任何串口输出，JTAG也无法连接。
他们第一反应是：“Flash驱动有问题？”、“Bootloader损坏？”、“芯片焊坏了？”
但我们知道，只要芯片还能供电，就有机会留下痕迹。
于是我们在旧版固件中埋入一个“自杀测试”：
void TestSuicide(void) {
unsigned int *p = (unsigned int*)0x00090000;
((void(*)(void))p)();
}
模拟跳转到非法地址。运行后，果然触发预取中止。
此时我们通过UART输出关键寄存器：
[ABORT] LR_abt: 0x0000_123C
CPSR: 0x6000_00D3
SPSR: 0x2000_001F
FAR : 0x0000_0000
FSR : 0x08
计算得出：故障指令地址 =
0x0000_123C - 4 = 0x0000_1238
反查MAP文件：
.text.main_entry 0x00001238 ... main.c
定位到了主函数入口附近的一次跳转。再一看链接脚本：
ENTRY(Main_Entry)
SECTIONS {
.text : {
*(.vectors)
*(.text)
} > FLASH_ORIGIN
}
问题来了：
FLASH_ORIGIN
定义为
0x00000000
，最大容量512KB（
0x0007FFFF
），但新版固件体积已达600KB！
linker毫不客气地把部分代码塞进了
0x00080000
以上区域——而这正是外部存储控制器未映射的空间。
结论： 链接脚本未适配新固件大小，导致入口函数落在非法区域 。
修复方法很简单：调整片选配置，扩展EMC地址映射，或优化代码分区。
但这背后的意义更大：如果没有预取中止机制，这个问题可能需要一周时间排查；有了它，我们只用了两个小时。
如何构建一套可靠的异常诊断框架？
你不需要每次都手动分析寄存器。我们可以封装一个轻量级的“异常侦探包”。
第一步：重定向异常向量表
必须保证前8个word都是合法指令，否则连异常处理自己都会崩。
典型做法是在启动文件中定义：
.section .vectors, "ax"
.globl _vectors_start
_vectors_start:
LDR PC, =Reset_Handler
LDR PC, =Undefined_Handler
LDR PC, =SWI_Handler
LDR PC, =PrefetchAbort_Handler
LDR PC, =DataAbort_Handler
LDR PC, =NotUsed_Handler
LDR PC, =IRQ_Handler
LDR PC, =FIQ_Handler
所有Handler都要指向有效函数，哪怕只是打印日志。
第二步：编写“裸体”异常处理函数
使用
__attribute__((naked))
防止编译器插入栈操作或其他潜在非法访问：
void __attribute__((naked)) PrefetchAbort_Handler(void)
{
__asm volatile (
"STMFD SP!, {R0-R3, R12, LR} \n\t" // 保存通用寄存器
"MRC p15, 0, R0, c6, c0, 0 \n\t" // 读FAR
"MRC p15, 0, R1, c5, c0, 0 \n\t" // 读FSR
"STR R0, [SP, #-4]! \n\t" // 临时压栈
"STR R1, [SP, #-4]! \n\t"
"MOV R0, LR \n\t" // 传参：LR_abt
"MRS R1, SPSR \n\t" // 传参：SPSR
"BL LogPrefetchAbort \n\t" // C语言日志函数
"B Reset \n\t" // 最终复位
);
}
然后在C层解析并输出：
void LogPrefetchAbort(unsigned int lr_abt, unsigned int spsr)
{
unsigned int far, fsr;
__get_far_fsr(&far, &fsr); // 内联汇编读取
uart_printf("\r\n[PREFETCH ABORT]\r\n");
uart_printf("Instr Addr: 0x%08X\r\n", lr_abt - 4);
uart_printf("SPSR : 0x%08X\r\n", spsr);
uart_printf("FAR : 0x%08X\r\n", far);
uart_printf("FSR : 0x%08X (%s)\r\n",
fsr, fsr == 0x08 ? "Ext PAbort" : "Unknown");
DumpModeFromSPSR(spsr); // 分析原运行模式
}
第三步：建立“异常指纹库”
长期收集不同场景下的异常日志，你会发现一些典型的模式：
| 现象 | 可能原因 |
|---|---|
LR_abt
总在中断向量附近
| NVIC配置错误，IRQ跳转到NULL |
SPSR
显示IRQ模式
| 在中断中修改了函数指针并立即调用 |
FAR=0
,
FSR=0x08
| 典型预取中止，地址由LR推算 |
FAR≠0
,
FSR=0x0C
| 数据访问段缺失，可能DMA越界 |
把这些做成checklist，下次遇到类似问题可以直接匹配。
为什么说这是每个嵌入式工程师的“必修课”？
因为在真实世界中，以下情况比比皆是：
- 客户现场没法接JTAG
- 量产设备不允许留调试接口
- Bootloader阶段根本没有调试支持
- 系统跑着跑着突然重启，日志全无
而预取中止异常就像一颗微型黑匣子，默默地记录着每一次“致命跳跃”的轨迹。
更重要的是，它的实现成本极低：
- 不需要操作系统
- 不依赖malloc或复杂库
- 即使栈都没初始化，也可以用SP做最基础的日志输出（比如点亮LED闪烁编码）
只要你愿意花半小时把它接通，未来就能省下几十个小时的盲目排查。
一个容易被忽视的设计细节：FAR的一致性管理
再说一遍重点： 预取中止不会自动更新FAR 。
这意味着如果你不清它，下一次数据中止发生时，FAR里可能还是几个月前某个已解决bug的残留地址。
更可怕的是，有些RTOS或库函数会在内部触发数据访问异常，而你的异常处理函数如果不区分类型，就会误把FAR当作预取中止的来源。
解决方案有两个：
✅ 方法一：进入每类异常时主动清理FAR
// 在PrefetchAbort和DataAbort开头都加这一句
__asm__("MCR p15, 0, %0, c6, c0, 0" :: "r"(0));
确保每次都是“干净”的上下文。
✅ 方法二：只信任LR_abt用于预取中止定位
既然FAR不可靠，那就干脆不用。坚持用
LR_abt - 4
推算故障地址，配合MAP文件反查符号，准确率更高。
毕竟， 最可靠的证据永远来自CPU自身的行为逻辑 ，而不是某个可能被污染的寄存器。
如何避免误报？外部硬件也很关键
有时候你会发现：明明地址是合法的，却频繁触发预取中止。
这往往不是软件的问题，而是硬件时序没调好。
比如：
- Flash访问周期太短，没等数据稳定就采样
- 外部SRAM未启用页模式，突发访问超时
- 地址线接触不良，偶发错位
这时你需要检查：
- 存储控制器（EMC/BSC）的等待周期（WAIT cycles）
- 片选信号的有效宽度
- 总线仲裁是否冲突
有些芯片手册明确写着：“若总线无响应超过N个周期，则产生中止信号。”
所以， 预取中止不仅是内存映射问题，也可能是时序问题的间接反映 。
建议在系统初始化早期就完成所有存储外设的配置，最好在第一条C代码运行前搞定。
否则，编译器生成的
.rodata
变量一旦落在未配置区域，还没进main()就挂了，你还以为是启动文件写错了……
让异常成为系统的“免疫细胞”
最后我想说的是：不要害怕异常。
恰恰相反，你应该欢迎它们的到来。
每一次预取中止，都是系统在说：“嘿，我差点干了件蠢事，幸亏你设置了防护！”
与其想着怎么屏蔽异常，不如思考如何让它更有价值：
- 把异常日志通过CRC校验保存到备份RAM
- 上电自检时回放上次异常记录
- 结合看门狗实现“异常→记录→复位→恢复”
- 在安全关键系统中，将多次异常上报云端监控
甚至可以设计一种“灰度发布”机制：在测试版本中允许某些非关键异常继续运行，仅记录而不复位，用于收集边缘场景数据。
这才是现代嵌入式系统应有的健壮性思维。
写在最后：那些年我们跳过的坑
回想这些年踩过的坑：
-
函数指针数组越界，跳到了
.bss区执行，触发中止 - 动态加载模块释放后未置空回调，下次定时器触发直接飞走
- 编译器优化导致常量池跨区，链接脚本没预留足够空间
- 中断向量表复制错误，HardFault Handler变成了NOP序列……
每一个，都可以通过预取中止的日志快速定位。
所以，请务必在你的下一个项目里：
✅ 开启预取中止异常处理
✅ 至少输出
LR_abt
和
SPSR
✅ 用UART/LED留下一点痕迹
✅ 把这套机制变成模板固化下来
别等到系统上线后再后悔：“要是当初留个日志就好了……”
毕竟， 最好的调试工具，不是JTAG，而是你提前埋好的那一行异常处理代码 。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
扫一扫
559
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
