arm跑飞 分析

当arm跑飞后，可以用ICE 追踪是哪边出错了：

1. 链接ICE， 修改Ice的mode，由 udf -> system. (因为跑飞了，在UDF)

2. 查看寄存器： LR对应callback function的地址； SP对应压栈的数据；

3. 在outFiles文件下输入： fromelf -c MICRON_ENTERPRISE_DEAN_B0KB_RAIN_DPP_DBG.axf > output.file 将axf转换文件格式：

4. LR对应的值查找对应的地址：

　假设： LR： 0x801c6300

 ClrAbortState
        0x801c62f8:    e59f23c0    .#..    LDR      r2,[pc,#] ; [0x801c66c0] = 0x4003674
        0x801c62fc:    e92d4010    .@-.    PUSH     {r4,lr}
        0x801c6300:    e5d21001    ....    LDRB     r1,[r2,#]
        0x801c6304:    e5d23000    ...    LDRB     r3,[r2,#]
        0x801c6308:    e1831401    ....    ORR      r1,r3,r1,LSL #
        0x801c630c:    e1c10000    ....    BIC      r0,r1,r0

　　那么出错的时候在函数 ClrAbortState里;

5.SP 对应压栈的地址

假设：0x04000B50

0x0C5208BC 0x04003A7C 0x0000032A 0x00000000 0x00000000 ********************
0x00000000    0x00000000    0x0001BDB4    0x00000000    0x00010770    ********************
0x04002604    0x00000001    0x00000000    0x000104E8    0x00000000    ********************

由于 0x0C5208BC 是一个无效的指向，所以看0x04003A7C ；

在map文件中看到

gWorkloadCtrl                            0x04003a7c   Data            Workload_Control.o(data_sram_zi)

所以跑飞的就跟这几个信息有关。