调试nuttx堆栈崩溃问题

最近调试nuttx程序崩溃问题，一开始从代码着手，我认为分析堆栈信息由sp找到上一层sp，一层层的查下去，这有点麻烦，而且我也需要查找相关资料，到底堆栈传递如何整
， 所以一开始用GDB调试，但是GDB居然抓不到任何信息！！！
最后只好分析堆栈信息，将nuttx堆栈检查之类的东西都打开，一下就打印出信息，pid xx堆栈满了，但是这是哪个线程呢？ 不知道，看代码，分析找到了一个占用大栈的程序，将栈改为堆，则工作正常了。
但怎么确认就是这个线程了，找同事讨论，同事已经将每个线程堆栈地址范围打印出来了，这一下子就确定了是哪个线程了！
但是栈崩掉之后，到底跑到哪条代码而造成系统崩溃呢？这个没有继续追究下去..........................
可惜，可惜，可惜
2017.9.5
这是堆栈崩溃后的日志：

nsh> \0x1b[Ksmart_test -c 1 -r 200 -t 10

nsh: smart_test: too many arguments

createup_hardfault: Hard Fault:

up_hardfault: IRQ: 3 regs: 20008f50

up_hardfault: BASEPRI: 00000000 PRIMASK: 00000001 IPSR: 00000003 CONTROL: 00000000

up_hardfault: CFAULTS: 00000400 HFAULTS: 40000000 DFAULTS: 0000000b BFAULTADDR: e000ed38 AFAULTS: 00000000

up_hardfault: R0: 200020b0 00000034 ffffffff ffffffff 200092d8 00000040 20002090 20007cb8

up_hardfault: R8: 00000007 000001b6 00000007 200091b0 000007ff 20008f98 08004051 0800407e

up_hardfault: xPSR: a1000000 PRIMASK: 00000000 (saved)

up_hardfault: PANIC!!! Hard fault: 40000000

up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 171 task: smart_test

up_dumpstate: sp: 20008ed0

up_dumpstate: stack base: 20009088

up_dumpstate: stack size: 00000fbc

up_dumpstate: stack used: 000002c0

up_stackdump: 20008ec0: 08000cd5 08017d14 08017c40 000002c0 08000cd5 08017d14 08017c40 000002c0

up_stackdump: 20008ee0: 08000cd5 08017d14 08017c40 000002c0 40000000 0800134d 00000000 00000007

up_stackdump: 20008f00: 200091b0 000007ff 20008f98 08004051 0800407e 00000000 00000001 08001249

up_stackdump: 20008f20: 20008f50 00000003 00000000 080016ef 20001d0c 08000eb1 00000000 20008f50

up_stackdump: 20008f40: 00000040 20002090 20007cb8 0800037f 20008f98 00000000 200092d8 00000040

up_stackdump: 20008f60: 20002090 20007cb8 00000007 000001b6 00000007 200091b0 200020b0 00000034

up_stackdump: 20008f80: ffffffff ffffffff 000007ff 08004051 0800407e a1000000 200065e0 20006610

up_stackdump: 20008fa0: 20009043 08003d93 00000000 0800b213 00000000 080016ef 20007c84 20007c84

up_stackdump: 20008fc0: 200065e0 08008d77 200065e0 00000003 0800b1dd 00000000 200091ac 200091ac

up_stackdump: 20008fe0: 00000007 08009473 00000005 20009043 200065e0 20003c40 00000000 20009043

up_stackdump: 20009000: 2000903c 2000011c 00000005 00000005 08008b4f 00000007 0000000c 00000074

up_stackdump: 20009020: 20002008 200090e0 200091e0 20009210 00000000 00000000 00000000 616d732f

up_stackdump: 20009040: 302f7472 7478742e 00000000 00000000 00000000 00000101 20007b70 00000000

up_stackdump: 20009060: 00000000 00000000 00000000 20008110 00000000 08001a81 00000000 00000000

up_stackdump: 20009080: 00000000 00000000 deadbeef 200090ac 200090b7 200090ba 200090bc 200090bf

up_registerdump: R0: 200020b0 00000034 ffffffff ffffffff 200092d8 00000040 20002090 20007cb8

up_registerdump: R8: 00000007 000001b6 00000007 200091b0 000007ff 20008f98 08004051 0800407e

up_registerdump: xPSR: a1000000 PRIMASK: 00000000 CONTROL: 00000000

寄存器R15分别代表崩溃时的PC指针，R14代表返回后要执行的指令， 如果上面红色文字所示
使用arm-none-objdump -S nuttx.bin> test.S，将elf文件转换为汇编文件，查看test.S中的地址R15处指令，可以看到是执行哪条指令崩溃的！
也可以通过R14来看是从哪个函数调用进来的！
哈哈，分析完毕！
2017.9.13