Cortex-M0 lockup状态和原因

现实的世界如此复杂，对于嵌入式系统而言, 有些异常，辅以一定的代码处理，可以恢复；有些异常，代码自身不一定有能力从异常中恢复。一个健全的系统，需要考虑各种异常的情况,甚至不能恢复的异常也需要考虑。

 

当Cortex-M0/M3遇到严重的异常时，它会将自己的PC指针置于某个地址处，并锁死自己。下面列举可能锁死的原因（译自ARMv6-M Architecture Reference Manual B1.5.15）

原因	发生时机	行为	锁死时的PC地址
启动时读向量表错误	启动时不能读SP或PC	锁死在优先级-1	0xFFFFFFFE
进入NMI中断时，读向量表错误	不能读NMI的中断向量	锁死在优先级-2	0xFFFFFFFE
进入HardFault中断时，读向量表错误	不能读HardFault的中断向量	锁死在优先级-1	0xFFFFFFFE
内存错误 - Instruction	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE
内存错误 - Imprecise Data	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE
内存错误 - Precise Data	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE
内存错误 - 进入NMI中断时，压栈内容出错	在进入NMI之前的优先级为-1(HardFault)	锁死在优先级-1或-2(跟实现相关)	0xFFFFFFFE
内存错误 - 出栈错误	出栈时发生错误	锁死在优先级-1或-2或进入HardFault中断	0xFFFFFFFE
SVC	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE
Usage Fault	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE
未定义指令	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE
断点(BKPT)	优先级-1或-2	锁死在当前优先级	0xFFFFFFFE

 

原因一堆，总之就一句话，排除硬件故障的话，就是程序出错了，然后PC就跑到0xFFFFFFFE处不回来了。

当这种情况出现时，用IAR+Nu-Link调试，会做静默处理，需要留意PC的值以便作出判定;

用Keil+Nu-Link调试，会尝试读PC处的内容，于是显示读不到数据的对话框。 

最后，总结一下，遇到锁死在0xFFFFFFFE时，可能的原因和排查办法：

1. 目标板没有上电，仅靠调试器管脚上的一点电流在运行。这种情况下可能电流不够，导致下载运行的程序根本就不对;

   建议：给目标板接上外接电源。

2. Keil太聪明，它认为你的板子应该有程序，所以不下载程序到班子，但是实际上板子可能是空白flash。

   例如：先用Keil下载并调试板子A；然后换上板子B，直接点Keil的“调试”。这时候Keil以为连接的还是板子A, 所以它并不再次下载。

   建议：每次调试之前，按F7重新link一下程序，Keil就保证会再次下载了。

3. Keil Project设定为：Debugger时不要下载程序。那板子上可能就没程序了。

   建议：打开对话框：Project->Options->Utilities->Update Target before Debugging，确信这一项有打上勾。

4. Nu-Link驱动中选择的“Chip Type”和目标板不匹配，运行的结果不可预料。

   建议：

   对于Keil, 打开对话框：Project->Options->Debug->Nu-Link Debugger->Settings，确信Chip Type没有和目标板一致。

   对于IAR, 打开对话框：Project->Options->General Options->Target->Device，确信Device类型和目标板一致。

   （Nu-Link 4117rc之后版本的Nu-Link, 会检测芯片类型，报告不一致的情况）。

5. Nu-Link/Keil关于flash utility的设定，没有选择擦除。

   Flash写之前需要擦除的，然而为了客户特殊需要以及和Ulink界面的一致，Nu-Link仍旧允许写之前不擦除。

   建议：写之前不擦除，用户会受到警告，请留意警告信息。

   如需修改此设定，可打开对话框：Project->Options->Utilities->Nu-Link Debugger->Settings->Download functions处修改。

6. 程序的确是写错了；

   建议：没有建议了^_^