当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)
所以跑飞的就跟这几个信息有关。