Cortex-M3-中断/异常的响应序列

Cortex-M3-中断／异常的响应序列

当CM3开始响应一个中断时，会在它看不见的体内奔涌起三股暗流：

• 入栈： 把8个寄存器的值压入栈.
• 取向量：从向量表中找出对应的服务程序入口地址.
• 选择堆栈指针MSP/PSP，更新堆栈指针SP，更新连接寄存器LR，更新程序计数器PC.

入栈

• 响应异常的第一个行动，就是自动保存现场的必要部分：依次把xPSR, PC, LR, R12以及R3‐R0由硬件自动压入适当的堆栈中：如果当响应异常时，当前的代码正在使用PSP，则压入PSP，即使用线程堆栈；否则压入MSP，使用主堆栈。一旦进入了服务例程，就将一直使用主堆栈。
• 假设入栈开始时，SP的值为N，则在入栈后，堆栈内部的变化如表9.1表示。又因为AHB接口上的流水线操作本质，地址和数据都在经过一个流水线周期之后才进入。另外，这种入栈在机器的内部，并不是严格按堆栈操作的顺序的——但是机器会保证：正确的寄存器将被保存到正确的位置. 如下图和表的第三列所示.

图1

表1

• CM3在看不见的内部打乱了入栈的顺序，这是有深层次的原因的。先把PC与xPSR的值保存，就可以更早地启动服务例程指令的预取——因为这需要修改PC；同时，也做到了在早期就可以更新xPSR中IPSR位段的值。
• 细心的读者一定在猜测：为啥袒护R0‐R3以及R12呢，R4‐R11就是下等公民？原来，在ARM上，有一套的C函数调用标准约定（《C/C++ Procedure Call Standard for the ARM Architecture》，AAPCS, Ref5）。个中原因就在它上面：它使得中断服务例程能用C语言编写，编译器优先使用被入栈的寄存器来保存中间结果（当然，如果程序过大也可能要用到R4‐R11，此时编译器负责生成代码来push它们。但是，ISR应该短小精悍，不要让系统如此操心——译者注）。
• 如果读者再仔细看，会发现R0‐R3, R12是最后被压进去的。这里也有一番良苦用心：为的是可以更容易地使用SP基址来索引寻址，（以及为了LDM等多重加载指令，因为LDM必须加载地址连续的一串数据）。参数的传递也是受益者：使之可以方便地通过压入栈的R0‐R3取出（主要为系统软件所利用，多见于SVC与PendSV中的参数传递）。

取向量

• 当数据总线（系统总线）正在为入栈操作而忙得团团转时，指令总线（I‐Code总线）可不是凉快地坐着看热闹——它正在为响应中断紧张有序地执行另一项重要的任务：从向量表中找出正确的异常向量，然后在服务程序的入口处预取指。由此可以看到各自都有专用总线的好处：入栈与取指这两个工作能同时进行。

更新寄存器

• 在入栈和取向量的工作都完毕之后，执行服务例程之前，还要更新一系列的寄存器：
• SP：在入栈中会把堆栈指针（PSP或MSP）更新到新的位置。在执行服务例程后，将由MSP负责对堆栈的访问。
• PSR：IPSR位段（地处PSR的最低部分）会被更新为新响应的异常编号。
• PC：在向量取出完毕后，PC将指向服务例程的入口地址。
• LR：LR的用法将被重新解释，其值也被更新成一种特殊的值，称为“EXC_RETURN”，并且在异常返回时使用。EXC_RETURN的二进制值除了最低4位外全为1，而其最低4位则有另外的含义。(图5 会有解释EXC_RETURN)
• 以上是在响应异常时通用寄存器的变化。另一方面，在NVIC中，也伴随着更新了与之相关的若干寄存器。例如，新响应异常的悬起位将被清除，同时其活动位将被置位。

异常返回

• 当异常服务例程执行完毕后，需要很正式地做一个“异常返回”动作序列，从而恢复先前的系统状态，才能使被中断的程序得以继续执行。从形式上看，有3种途径可以触发异常返回序列，如下表所示；不管使用哪一种，都需要用到先前储的LR的值。

表2

 

• 有些处理器使用特殊的返回指令来标示中断返回，例如8051就使用reti。但是在CM3中，是通过把EXC_RETURN往PC里写来识别返回动作的。因此，可以使用上述的常规返回指令，从而为使用C语言编写服务例程扫清了最后的障碍（无需特殊的编译器命令，如__interrupt）。

在启动了中断返回序列后，下述的处理就将进行：

• 出栈：先前压入栈中的寄存器在这里恢复。内部的出栈顺序与入栈时的相对应，堆栈指针的值也改回去。
• 更新NVIC寄存器：伴随着异常的返回，它的活动位也被硬件清除。对于外部中断，倘若中断输入再次被置为有效，悬起位也将再次置位，新一次的中断响应序列也可随之再次开始。

嵌套的中断

• 在CM3内核以及NVIC的深处，就已经内建了对中断嵌套的全力支持，根本无需使用用汇编写封皮代码(wrapper code)。事实上，我们要做的就只是为每个中断适当地建立优先级，不用再操心别的。表现在：
• 第一、 NVIC和CM3处理器会为我们排出优先级解码的顺序。因此，在某个异常正在响应时，所有优先级不高于它的异常都不能抢占之，而且它自己也不能抢占自己。
• 第二、 有了自动入栈和出栈，就不用担心在中断发生嵌套时，会使寄存器的数据损毁，从而可以放心地执行服务例程。
• 然而，有一件事情却必须更加一丝不苟地处理了，否则有功能紊乱甚至死机的危险，这就是计算主堆栈容量的最小安全值。我们已经知道，所有服务例程都只使用主堆栈。所以当中断嵌套加深时，对主堆栈的压力会增大：每嵌套一级，就至少再需要8个字，即32字节的堆栈空间——而且这还没算上ISR对堆栈的额外需求，并且何时嵌套多少级也是不可预料的。如果主堆栈的容量本来就已经所剩无几了，中断嵌套又突然加深，则主堆栈有被用穿的凶险。这就好像已经表现出了高血压危象的时候，情绪又一激动，就容易导致中风一般。在这里，堆栈溢出同样是很致命的，它会使入栈数据与主堆栈前面的数据区发生混迭，使这些数据被破坏；若服务例程又更改了混迭区的数据，则堆栈内容被破坏。这么一来在执行中断返回后，系统极可能功能紊乱，甚至当场被一击必杀——程序跑飞/死机！
• 另一个要注意的，是相同的异常是不允许重入的。因为每个异常都有自己的优先级，并且在异常处理期间，同级或低优先级的异常是要阻塞的，因此对于同一个异常，只有在上次实例的服务例程执行完毕后，方可继续响应新的请求。由此可知，在SVC服务例程中，就不得再使用SVC指令，否则将fault伺候。

咬尾中断

• CM3为缩短中断延迟做了很多努力，第一个要提的，就是新增的“咬尾中断”（Tail‐Chaining）机制。当处理器在响应某异常时，如果又发生其它异常，但它们优先级不够高，则被阻塞——这个我们已经知道。那么在当前的异常执行返回后，系统处理悬起的异常时，倘若还是先POP然后又把POP出来的内容PUSH回去，这不成了砸锅炼铁再铸锅，白白浪费CPU时间吗，可知还有多少紧急的事件悬而未决呀！正因此，CM3不会傻乎乎地POP这些寄存器，而是继续使用上一个异常已经PUSH好的成果，消灭了这种铺张浪费。这么一来，看上去好像后一个异常把前一个的尾巴咬掉了，前前后后只执行了一次入栈／出栈操作。于是，这两个异常之间的“时间沟”变窄了很多。如下两图:

图2

图3

晚到（的高优先级）异常

• CM3的中断处理还有另一个机制，它强调了优先级的作用，这就是“晚到的异常处理”。当CM3对某异常的响应序列还处在早期：入栈的阶段，尚未执行其服务例程时，如果此时收到了高优先级异常的请求，则本次入栈就成了为高优先级中断所做的了——入栈后，将执行高优先级异常的服务例程。可见，它虽然来晚了，却还是因优先级高而受到偏袒，低优先级的异常为它“火中取栗”。
• 比如，若在响应某低优先级异常#1的早期，检测到了高优先级异常#2，则只要#2没有太晚，就能以“晚到中断”的方式处理——在入栈完毕后执行ISR #2，如图4所示。如果异常#2来得太晚，以至于已经执行了ISR #1的指令，则按普通的抢占处理，这会需要更多的处理器时间和额外32字节的堆栈空间。在ISR #2执行完毕后，则以刚刚讲过的“咬尾中断”方式，来启动ISR #1的执行。

图4

异常返回值(EXC_RETURN)

• 前面已经讲到，在进入异常服务程序后，LR的值被自动更新为特殊的EXC_RETURN，这是一个高28位全为1的值，只有[3:0]的值有特殊含义，如图5所示。当异常服务例程把这个值送往PC时，就会启动处理器的中断返回序列。因为LR的值是由CM3自动设置的，所以只要没有特殊需求，就不要改动它。

图5

可以得出，合法的EXC_RETURN值共3个:

0xFFFF_FFF1  //返回handler模式
0xFFFF_FFF9  //返回线程模式，并使用主堆栈(SP=MSP)
0xFFFF_FFFD  //返回线程模式，并使用线程堆栈(SP=PSP)

• 如果主程序在线程模式下运行，并且在使用MSP时被中断，则在服务例程中LR=0xFFFF_FFF9（主程序被打断前的LR已被自动入栈）。
• 如果主程序在线程模式下运行，并且在使用PSP时被中断，则在服务例程中LR=0xFFFF_FFFD（主程序被打断前的LR已被自动入栈）。