PC指针指向0xFFFFFFFE是怎么回事儿？

在工作中遇到了一颗cortex-m0内核的问题芯片，它的现象是程序在正常执行一段时间后跑飞，于是就着这个问题芯片深挖了一下。

通过调试模式执行代码寻找问题时，发现程序跑飞后cortex-m0的寄存器状态如下：

通过寄存器状态发现了一个问题，PC指针指向了0xFFFFFFFE，对于一个正常执行的程序来说，PC指针应该指向的是下一条运行的指令地址，很明显0xFFFFFFFE不是我们存放代码的地址，通过M0权威指南和网上查到的资料来看，PC指针指向0xFFFFFFFE时，这种PC指针的异常状态有个专用的名字：lockup。在此状态下，处理器停止执行指令并确认lockup状态信号。

在初步了解了PC指针指向0xFFFFFFFE的身世后，我们进一步了解出现lockup的原因，根据《ARM Cortex M0权威指南》的描述，我罗列了一下lockup出现的原因：

浅谈一下这些出错原因，先来看一张M0的异常图：

再对比一下原因，大部分的lockup原因都是排行榜前几的大哥相关，排行榜前几的大哥做的事情都是关乎芯片正常执行的生死攸关的大事，这时候就不是能够轻易打断的，
第一个NMI执行期间产生错误，本身能跑到NMI中断的异常情况都是严重的系统异常和故障，在此时，又来一个hardfault，CPU lockup摆烂也是能理解的事情。

第二个原因：hardfault处理期间再产生一个hardfault，也是和第一个原因差不多的道理，hardfault中产生的新的hardfault怎么办呢？自己再嵌套一层相同优先级的hardfault中断好像也不合适吧，pending等待也不好吧，毕竟都hardfault了，肯定希望CPU赶紧处理了，CPU里外不是人，一合计索性lockup，摆烂了。

第三个原因：在NMI或hardfault处理中，包含了SVC操作，这个行为本身就是不被系统允许的，SVC的优先级在NMI和hardfault之下。

第四个原因：复位期间总线错误响应，在复位期间，CPU从存储器读取栈指针的时候产生了错误，无法得到栈指针的初始值，或者无法确定复位向量，这些情况下，处理器甚至不能正常操作，不摆烂还能干嘛呢？

最后一个原因：在异常退出且使用MSP的xPSR出栈期间，总线错误响应，这种情况下，xPSR无法确认，处理器无法获取到系统的正确优先级，也会导致lockup。

总的来说，就是系统本身要对一切的异常处理得心应手，对自身状态也要了如指掌，当它发现自己无法解决当前问题或者无法确认自身状态时，它就自闭（lockup）了。