RTThread中HardFault的定位

1万 · 2022-2-7 13:41

错误如下：

hard fault 处理流程：

1万 · 2022-2-7 13:43

rtt出错时候的输出：

psr: 0x000b0000

r00: 0x00000001

r01: 0x00000000

r02: 0x00000010

r03: 0x00000001

r04: 0x00000000

r05: 0x00000000

r06: 0x00000000

r07: 0x00000000

r08: 0xdeadbeef

r09: 0xdeadbeef

r10: 0xdeadbeef

r11: 0xdeadbeef

r12: 0xffffffff

 lr: 0x08003185

 pc: 0x00000000

hard fault on thread: main



thread   pri  status      sp     stack size max used left tick  error

-------- ---  ------- ---------- ----------  ------  ---------- ---

at_clnt    9  suspend 0x00000100 0x00000800    14%   0x00000005 000

tshell    20  suspend 0x000000cc 0x00001000    05%   0x00000009 000

tidle0    31  ready   0x00000074 0x00000400    11%   0x0000001b 000

main      10  running 0x000003a8 0x00000800    75%   0x00000003 000

FPU active!

usage fault:

SCB_CFSR_UFSR:0x02 INVSTATE

1万 · 2022-2-7 14:16

上述寄存器信息中，lr寄存器中的值为0x08003185 ，此值为进入fault异常中断之前的lr的值。

我们知道lr为连接寄存器里面保存的是调用子程序之前的PC的值。因为内部使用了指令流水线，读 PC 时返回的值是当前指令的地址+4 ，所以进入异常之前自动加载到lr的值也为调用子程序前的指令地址+4。由于PC的最低位保存ARM/Thumb 运行状态，Cortex-M3只能运行在Thumb 状态，即LSB = 1。所以我们想要找到出错误程序的指令位置，只需要对打印出来的lr的值减去5即可。

0x08003185 减去5后为0x08003180 说明我们程序出错位置在PC = 0x08003180 附近。

在Disassembly窗口下，我们找到0x08003180 指令位置:

1万 · 2022-2-7 14:22

再看打印结果：

还有代码位置：

结合前面0x08003180的反汇编，问题应该处在这个附近。

RTThread中HardFault的定位

相关下载

相关帖子

突出贡献奖章

沉静之湖泊

七世轮回

技术奇才奖章