AM335 data abort 异常检测方法

AM335 系统环境以及调试方法

由于AM335我使用的是裸机，没有操作系统，调试的时候就特别麻烦，只能靠打印信息去看问题，但是当出现硬件复位这样的情况时，很难找到问题所在点，大多数时候只能靠打印信息确定大概出现的位置，然后靠猜测去定位异常的位置。但是在实际项目中很多打印信息是要去掉的，否则影响程序的运行效率，有的时候程序运行很久，突然出现了data abort，这种情况就必须借助objdump工具去定位异常的代码段。

当出现硬件复位，打印信息显示data abort

data abort
pc : [<99f160ec>]	   lr : [<99f16da9>]
reloc pc : [<808390ec>]	   lr : [<80839da9>]
sp : 98eb4d48  ip : 00002800	 fp : 00000017
r10: 99f46b9b  r9 : 98ebced8	 r8 : 0000000d
r7 : 00000000  r6 : 9d7b5174	 r5 : 9d7baf70  r4 : 00220022
r3 : 00000000  r2 : 00000050	 r1 : 00000050  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32
Resetting CPU ...

resetting ...

使用objdump反汇编elf文件

根据打印信息 ，使用arm-none-eabi-objdump.exe -l -S app.elf > app.s 工具反汇编app.elf文件到app.s中。因为我使用的编译器是arm-none-eabi,所以使用的是arm-none-eabi-objdump，这里可以根据自己使用编译器灵活调整。

-l表示反汇编的时候打印出函数所在位置。

编译app.elf文件注意事项

注意编译app.elf文件的时候要加上调试信息，不使用-s选项，否则反汇编出来的文件无法查看到函数信息。

gcc 编译选项 -s 可以裁剪执行程序的信息，删除可执行文件中所有符号表和重新定位信息，以压缩可执行文件，导致gdb调试无效

经常使用stm32的小伙伴对elf文件应该再熟悉不过了，怎么编译elf文件这里就不再细聊

异常代码段的定位

查看app.s文件，搜索reloc pc 的值，找到所在位置，这个位置表示进入data abort 之前PC所在的位置，一般就是导致硬件复位的问题所在点