RTT报错时 提示信息分析 求助！！！

hust_yojin

STM32的板子 跑RTT，出现以下报错信息，请问哪里有对这组显示信息前面符合表示意义的介绍？
比如，PSR：0x21000000 表示什么？r00。。r12表示什么？lr、pc 表示什么？
还有，在后面的thread信息中SP：0x00000040表示什么？

psr: 0x21000000
r00: 0x20009510
r01: 0x10000000
r02: 0xf0000000
r03: 0x00000020
r04: 0x61642e30
r05: 0xdeadbeef
r06: 0xdeadbeef
r07: 0xdeadbeef
r08: 0xdeadbeef
r09: 0xdeadbeef
r10: 0xdeadbeef
r11: 0xdeadbeef
r12: 0x20008ef0
lr: 0x0801064d
pc: 0x0801064c
hard fault on thread: daily



thread  pri  status      sp     stack size max used   left tick  error
-------- ---- ------- ---------- ---------- ---------- ---------- ---
daily    0x1e ready   0x00000040 0x00005000 0x00000308 0x00000003 000
rf       0x19 suspend 0x000000c8 0x00002800 0x000000d0 0x00000006 000
apportio 0x1b suspend 0x00000080 0x00002800 0x00000080 0x00000005 000
ctrl     0x17 suspend 0x000003e0 0x00002800 0x000003e0 0x00000005 000
gprs     0x19 suspend 0x00000180 0x00002800 0x00000180 0x00000005 000
tcpip    0x0c suspend 0x000000dc 0x00000400 0x000000dc 0x00000014 000
tshell   0x14 suspend 0x00000094 0x00000800 0x00000094 0x0000000a 000
etx      0x0f suspend 0x00000098 0x00000200 0x00000098 0x00000010 000
erx      0x0f suspend 0x00000090 0x00000200 0x00000090 0x00000010 000
tidle    0x1f ready   0x00000044 0x00000100 0x00000044 0x0000000e 000
init     0x08 close   0x00000068 0x00002800 0x000002e8 0x00000013 000
usage fault:
SCB_CFSR_UFSR:0x02 INVSTATE

aozima

ARM cortex-M 系列 HardFault的诊断： http://www.rt-thread.org/phpBB3/topic2300.html

问题追踪

上面测试出了问题，是我们人为设置的故障，但在平时调试中出了问题如何追综呢？
以非对齐访问为例，开发环境使用MDK。

1. 进入JTAG仿真状态，并触发非对齐异常。
此时串口会打印出异常时的寄存器值，此时停止仿真器发现程序停在rt_hw_hard_fault_exception中。

2. 根据上面打印出来的寄存器，提取出关键值是 pc: 0x08000386
我们在MDK的command窗口中输入 pc = 0x08000386

1.        239:     p = (int *)0x03;
   
2.     0x08000384 2403      MOVS     r4,#0x03
   
3.        240:     value = *p;
   
4.     0x08000386 6820      LDR      r0,[r4,#0x00]
   
5.     0x08000388 9000      STR      r0,[sp,#0x00]

复制代码

分析 #386 这条指令从 R4+0 的问题读取4字节到R0中，
先前打印出的R4的值为 r04: 0x00000003
因此可以确定为这是因为地址不对齐造成的。

当然，具体情况要具体分析，有时候某个步骤出现问题并不会马上崩溃，
而是过一段时间以后才出问题，因此要结合上下文综合分析。
比如上面这个案例真正有问题的指令是 0x08000384。

根据以上的案例，并结合实际调试经验，相信大家可以更快地找出问题。