嵌入式调试ARM程序跑飞现象的跟踪

2019-07-13 06:20发布

最近在调试2410的过程中,经常出现程序跑飞的现象,跟踪进行后发现。。。所以决定把它记录下来。
现象:
调试用的是技创ARM仿真器(兼容multi-ICE)和ADS1.2,板子外扩Nand
FLASH(装有Bootload)和SDRAM。当将程序烧到FLASH运行时会出现无规律的死机。用仿真器仿真时情况是这样:当CPU复位后,第一次装载程序执行时,情况与烧到FLASH运行时一样。但如果将运行的程序停下来(无论有无跑飞情况下),再重新装载(CPU复位后第二次及以后装载)时,运行到下述程序中的“msr     cpsr_cxsf,r1”就跑飞。
     bic     r0,r0,#MODEMASK | NOINT     ;IRQ、FIQ位清0
     orr     r1,r0,#SVCMODE
     msr     cpsr_cxsf,r1         ;SVCMode    ;充许中断后,使程序跑飞
     ldr     sp,=SVCStack
过程:
上面是启动代码中初始化堆栈处的程序,就是这里允许了中断后,产生中断才使程序跑飞的。打开
MEMORY窗口,查看各中断挂起寄存器,发现有定时器等中断请求,此时我直接在MEMORY窗口中给该标志位写“1”清除它们,INTPEND中的能清除,SRCPND清不掉,奇怪?原来目标CPU的定时器还在不停的运行着呢(习惯了51仿真的同志要注意这一点,哈哈!包括我)!刚一清除,又立即溢出了,尽管正处在停止运行的仿真状态。现在可以解释为什么CPU复位后第一次装载运行不会使程序跑飞了,因为复位后,各寄存器都变成初始态,定时器也还没有开启,所以也就不会触发中断。而当开启了定时器后,再装载程序时,定时器已经溢出,触发了中断。那么为何一进中断就会使程序跑飞呢?于是就在命令窗口中输入br   0x18,再执行程序,原来IRQ中断入口0x18的内容已从原先的0xea000047被改成了0x6b736564,反汇编代码如下:
00000018     [0x6b736564] * blvs      0x1cd95b0
CPU复位后的代码如下:
00000018     [0xea000047] * b         0x13c
啊!这怎么能被改掉!这不是Nand
FLASH的内容吗?接着我就用MEMORY窗口观察该处,再单步执行我的程序,果然跟踪到了修改该处的程序,可是没有写NandFLASH的操作,源程序如下:    
typedef   struct   software_config_system
{
int     software_flag;
CHAR    curfont[20];
     。。。。。。
} software_config, *s_config;                 //定义数据结构及其指针

unsigned  
CHAR   InitsoftDescription(void)
{
if   (s_config->software_flag != 0x2)
     {
         s_config->software_flag = 0x2;        //给指针指向的地址处赋值
         memcpy(s_config->curfont, "hanzi", 5);
。。。。。。
}
}  
原来是定义了一个全局的结构指针变量(s_config),由于没有对它进行赋值,而它默认的初始值为0,所以对他进行读写,也就对0x0开始处的地址进行读写。而且此时这段区间的NAND
FLASH已被映射成Boot internel SRAM了,所以可以随机读写(这点一定要注意)。
总结:
1.在仿真情况下(即使停止程序的运行),目标CPU的各外围还是在工作的,如定时器等。
2.当将系统设计成NAND
FLASH启动时,0x0开始处的4K地址空间已是CPU的内部SRAM了,可以像其它RAM一样随意读写,此时定义全局的指针变量时,一定要记得赋值,否则就会修改这部分的代码。
3.在用仿真器仿真时,可以在初始化堆栈的前面加一些关闭定时器及清中断标志等代码,以免在没有复位CPU的情况下,程序还没执行到main函数就频繁产生中断。

http://t86905379.blog.163.com/blog/static/2924393201061272932431/