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

最近在调试2410的过程中，经常出现程序跑飞的现象，跟踪进行后发现。。。所以决定把它记录下来。
现象：
调试用的是技创ARM仿真器（兼容multi-ICE）和ADS1.2，板子外扩NandFLASH（装有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
啊！这怎么能被改掉！这不是NandFLASH的内容吗？接着我就用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函数就频繁产生中断。