中断响应
Cortex-M3 单片机在开始响应一个中断时，会进行以下三个操作：
- 寄存器入栈，将寄存器的值压入栈
- 取向量：从向量表中找出对应的服务程序入口地址
- 选择堆栈指针 MSP/PSP，更新堆栈指针SP，更新连接寄存器LR，更新程序计数器PC
响应中断的第一个动作，就是自动保存现场的必要部分：依次把 xPSR, PC, LR, R12 以及 R3-R0 由硬件自动压入适当的堆栈中。
当响应异常时，当前的代码正在使用 PSP，则压入 PSP，也就是使用进程堆栈；否则就压入 MSP，使用主堆栈。一旦进入了服务例程，就将一直使用主堆栈。
入栈顺序以及入栈后堆栈中的内容，如下图所示。在自动入栈的过程中，把寄存器写入堆栈内存的时间顺序，并不是与写入的空间顺序相对应的。但是机器会保证：正确的寄存器将被保存到正确的位置 。
![]() ![]()
先把PC与 xPSR 的值保存，就可以更早地启动服务例程指令的预取——因为这需要修改PC；同时，也做到了在早期就可以更新 xPSR 中 IPSR 位段的值。 取出中断服务例程地址，从中断向量表中找出正确的异常向量，然后在服务程序的入口处预取指。这部分由指令总线（I-Code总线）完成。
在入栈和取向量操作完成之后，执行中断服务例程之前，还要更新一系列的寄存器：
- SP：在入栈后会把堆栈指针（PSP 或 MSP）更新到新的位置。在执行服务例程时，将由 MSP 负责对堆栈的访问。
- PSR：更新 IPSR 位段（PSR的最低部分）的值为新响应的异常编号。
- PC：在取向量完成后， PC将指向服务例程的入口地址。
- LR：在出入 ISR 的时候， LR 的值将重新诠释为 “EXC_RETURN”。在异常进入时由系统计算并赋给 LR，并在异常返回时使用它。（后面会讲解 EXC_RETURN）
以上是在响应异常时通用寄存器的变化。另一方面，在 NVIC 中，也会更新若干个相关有寄存器。
在完成以上工作之后，系统开始执行中断服务程序里的指令。当指令执行完毕，进入中断返回处理阶段。
中断返回
当异常服务例程执行完毕后，需要做一个“异常返回”动作，从而恢复先前的系统状态，才能使被中断的程序得以继续执行 。触发中断返回的指令：
![]() 中断返回值前面已经讲到，在进入异常服务程序后，将自动更新 LR 的值为特殊的 。这是一个高 28 位全为1的值，只有[3:0] 的值有特殊含义：![]()
当中断服务例程把这个值送往 PC 时，就会启动处理器的中断返回操作。因为 LR 的值是由 CM3 自动设置的，所以只要没有特殊需求，就不要改动它。 总结一下上表，可以得到，合法的 EXC_RETURN 值共3个：
![]() 如果主程序在线程模式下运行，并且在使用 MSP 时被中断，则在服务例程中 LR=0xFFFF_FFF9（主程序被打断前的 LR 已被自动入栈）。 如果主程序在线程模式下运行，并且在使用 PSP 时被中断，则在服务例程中 LR=0xFFFF_FFFD（主程序被打断前的 LR 已被自动入栈） 。这样描述可能比较抽象，不好理解。那就通过两张图来直观感受一下。主程序运行在线程模式，且使用主堆栈，进入中断后，以及有中断嵌套情况下，模式切换和 LR 的变化如下图。![]()
如果主程序在 Handler 模式下运行，则在服务例程中 LR = 0xFFFF_FFF1（主程序被打断前的LR已被自动入栈）。这时的所谓“主程序”，其实更可能是被抢占的服务例程。事实上，在嵌套时，更深层 ISR 所看到的 LR 总是 0xFFFF_FFF1。 主程序运行在线程模式，且使用进程堆栈的情况下，LR 值的变化如下
![]() 通过这两张图，可以很好地理解异常返回值的变化情况。 中断嵌套Cortex-M3 内核单片机支持中断嵌套，即高优先级中断可以抢占低优先级去执行指令。我们要根据实际使用情况，为每个中断建立适当的优先级。NVIC 和 CM3 处理器会根据优先级的设置来控制抢占与嵌套行为。有了自动入栈和出栈，我们不用担心在中断发生嵌套时，会使寄存器的数据损毁。![]()
我们知道，所有服务例程都只使用主堆栈（MSP）。所以当中断嵌套加深时，对主堆栈的压力会增大：每嵌套一级，就至少再需要8个字，即32字节的堆栈空间（这没算上 ISR 对堆栈的额外需求），并且何时嵌套多少级也是不可预料的。 如果主堆栈的容量本来就已经所剩无几了，中断嵌套又突然加深，则主堆栈有溢出的凶险。堆栈溢出是很致命的，新入栈数据会覆盖掉主堆栈前面的数据，数据遭到了破坏。
若在服务例程返回前混迭区的数据又被更改了，则在执行中断返回后，系统极可能功能紊乱，甚至出现程序跑飞的问题。
要注意的，相同的异常(中断)是不允许重入的。因为每个异常都有自己的优先级，并且在异常处理期间，同级或低优先级的异常是要阻塞的。
因此对于同一个异常，只有在上次实例的服务例程执行完毕后，方可继续响应新的请求。因此，在 SVC 服务例程中，就不得再使用SVC指令，否则将产生 fault 现象。
咬尾中断
Cortex-M3 内核为了缩短中断延迟，新增了 “咬尾中断” 机制。
当处理器在响应某个中断时，如果又发生低优先级或者相同优先级中断，则被阻塞。在当前的中断执行返回后，系统处理悬起的中断时，不再先POP，然后又把 POP 出来的内容PUSH回去；而是继续使用上一个中断已经 PUSH 好的成果。
这么一来，看上去好像后一个中断把前一个中断的尾巴咬掉了，前前后后只执行了一次 入栈／出栈 操作。于是，这两个异常之间的“时间沟”变窄了很多。
![]() 晚到中断 CM3 的中断处理还有另一个机制，这就是“晚到的异常处理”。当 CM3 对某异常的响应序列还处在早期：入栈的阶段，尚未执行其服务例程时，如果此时收到了高优先级异常的请求，则本次入栈就成了为高优先级中断所做的了。入栈后，将执行高优先级异常的服务例程。可见，它虽然来晚了，却还是因优先级高而优先执行。
| 
楼主
标题置顶
标题高亮
