凡是靠软件支撑的嵌入式系统都会发生复位现象，如果没有发生过复位，那么很有可能会发生另外一种更糟糕的情况，系统吊死，陷入了死循环，你根本就不知道它到底运行到了哪里。也有可能是你的能力所限，异常中断没有写好，虽然处理器发生了异常，但你没有去处理。所以从这来看，发生了复位还不算最坏，至少系统能恢复，只要不是经常发生，没准你的客户始终都发现不了，还会夸你的产品很好。
    现在的处理器已经做的很好，只要你对它的工作原理稍微有点了解，那么你就可以写出适当的代码，当发生异常的时候，根据现场保留的故障诊断信息，来定位出错的根源。至于为什么会复位，本质来说是你的软件自己让它复位的（最常用的是看门狗），常见的DEMO程序，异常中指分之，只是些个死循环，在实际的产品中是万万不能这样操作的。
   对于各种处理器，异常一般会有3种：
    1）预取指中止，也就是说取得指令地址不正确，因为处理器都会有一些保留地址，这些地址CPU是不能访问的，万一进行访问，就说明程序执行出错了。
    2）数据中指，也就是说访问的数据地址不正确，原因同上。
    3）指令错误，顾名思义，指令译码出错。
   在如上的三种情况，软件都必须要处理，简单的话，开看门狗，对系统进行复位，负责任的话，可以保留现场信息，留着后面的程序员来定位原因。
   当然还有高档的CPU，这种异常是一种特殊的处理，比如地址重映射等，这里不关注，需要特殊处理。
    对于一个稍微复杂点的嵌入式软件，它会专门作一个故障诊断的功能，当系统发生警告或者错误的时候进行特殊处理，比如内存不足，当错误积累到一定程度，系统自动复位，这种是一种纠错处理，处理器并未发生异常。

    以ARM7为例，我们知道在用户模式下我们常用的R0-R15以及CPSR共17个寄存器，其中R15是用作PC指针，R14用作函数返回指针，R13用作堆栈指针。那么发生异常后我们怎么做才能给以后提供足够的定位信息呢？
    1）根据异常模式下的R14找出USER模式下的PC指针，因为这个时候已经发生了处理器模式切换。
    2）切换到特权模式访问用户模式的SP指针，通过SP指针，保存堆栈数据到RAM（注意这片RAM开机不要被初始化，可以通过编译配置完成）。
    3）复位系统，开机检测到异常开机，把诊断信息记录到文件系统。
    4）用工具读出文件到PC，对比编译的符号文件，一般是MAP文件，或者使用其他工具，进行分析，不出意外，很快就能找出复位的原因。

    有些处理器会有指令执行过程中总线记录的环形RAM，每当指令执行，总线访问的地址，以及访问方式会实时记录下来，当有异常发生的时候，这片RAM区域会自动锁死，只能访问，不能改写，同样可以记录下来，保存到文件系统，供以后分析。

   其实这里还没有说为什么处理器会产生异常，从我来看，绝大多数的异常内存越界引起的，比如
     U32  buf[1];
     for(i = 0; i < 10; i++)
     {
         buf[i] = 0xFFFFFFFF;
     }
  
   上述代码在语法上是没有任何问题的，但执行的过程中就会发生异常。因为局部变量(buf[])都是从堆栈中申请的，下面的那个循环就会把堆栈中其他地址的内容都改写成0xFFFFFFFF，如果当地址访问的话就发生了错误。
   还有最常见的堆栈溢出，也就是堆栈空间开小了，申请的局部变量跑到堆栈以外了，改写了其他地方的RAM，引起处理器异常。

     以上只是简单说一下原理，具体仍需要对处理器稍微有些了解，不是朝夕就能立刻生效的，ARM的话可以参考《ARM体系机构与编程》，其实这本书就是ARM公司的英文文档的精简翻译，看看英文原版也未尝不可。