Cortex-M3 PendSV 中断系统调用说明

uqHZau · 发表于 2021-2-4 10:03

EDA365欢迎您登录！

您需要登录才可以下载或查看，没有帐号？注册

x

PendSV异常是和系统调用有些类似，cpu 需要手动将往NVIC 的PendSV 悬起寄存器中写1，然后产生中断，系统调用（SVC）是cortex-M3  CPU执行 SVC指令之后产生中断（ARM中一般是SWI 指令），都是软件的方式产生的中断，称其为内中断。

PendSV 和SVC  两个内中断的不同之处在于：

SVC指令执行之后，必须立即响应（保证能够立即硬件入栈r0-r3等寄存器，这是因为SVC中断需要传递参数到中断模式，所以必须立即响应，保证寄存器中存储的参数不被破坏，另一个原因是用户态程序，即线程模式的程序有的时候必须得到SVC中断响应函数的返回值才能继续执行，否则强行继续执行，将会出错），SVC的中断服务程序（ISR）立即执行，如果此时有别的ISR正在执行，且此中断的优先级比SVC的优先级高，将会产生硬fault，

（注：SVC通常在用户级线程模式下运行，但可以在特权级线程模式或者handler模式下运行，详见《cortex m3 权威指南》第12章，非基级的线程模式一节，如果在一个中断的ISR中调用 SVC，而且此ISR的优先级比SVC的优先级高，那么会产生硬fault，这是合理的，SVC必须立即得到响应，但是响应过程中允许被其他中断打断  例如在svc中断触发后，开始硬件入栈，但svc的ISR还没有开始执行，此时来了个优先级比SVC优先级更高的中断，那么优先级高的中断将以晚到中断的形式执行，执行完毕后 SVC的ISR再以  咬尾中断的形式执行）

SVC中断和其他中断还有不同之处，  其他中断一般都是不需要参数和返回值的，  所以中断触发之后的硬件入栈之后和执行出栈序列之前，中断的ISR一般是不修改保存在栈的R0-R3、xpsr、PC  和 LR 寄存器的，（也有特殊情况，例如上述提到过的《cortex m3 权威指南》第12章，非基级的线程模式一节），但是SVC中断是可能需要参数或者返回值的，  参数和返回值要借助  R0-R3寄存器来传递，  考虑到cortex-m3的晚到中断、咬尾中断等硬件机制，  SVC触发后， SVC的ISR执行过程中不能直接读取R0-R3寄存器获取参数，而是要到栈中读取保存的R0-R3寄存器的值，来获取参数，SVC的ISR 返回  返回值的时候，也不能直接向R0寄存器中写入返回值，出栈序列执行后，R0的值会被栈中保存的R0的值覆盖，正确的做法是，修改栈中保存的R0的值，修改为要返回的值

注：这里说的线程模式 handler模式  特权级用户级的关系如下：

SVC一般在用户线程模式下执行。它设计的本意就是让用户模式完成到普通模式的切换。

PendSV中断，一般在特权模式下往 NVIC 的PendSV 悬起寄存器中写1，来触发，一般在SysTick中断的ISR中执行，也就是Handler模式下并且，PendSV的优先级一般设置成最低，PendSV的ISR一般等到其他中断全部响应完成后，再响应，PendSV（悬起异常）设计的理念就是可以将此异常悬起，这样就可以完美应用在上下文切换的场景中。上下文切换可以再SVC和SysTick的ISR中完成，这里只说SysTick（系统滴答时钟中断），如果SysTick发生时，程序执行在用户级的线程模式，则没有问题，如下图：

但是如果，Systick发生时，是在其他中断的ISR中，则系统是不允许系统调用发生的，如果允许将会产生如下效果：

我们可以看到，IRQ中间被中断了，并且中断的时间包含上下文切换以及任务B的一个时间片，这个时间是不确定的，IRQ的没有得到及时的响应，这在实时系统中是坚决不允许的。所以就引入了 PendSV，如果在SYSTICK来临的时候，检测到有IRQ在执行，就延缓上下文切换，在SYSTICK的ISR中使用PendSV悬起一个异常，等之前的IRQ执行完之后，在执行上下文切换，如下图：

事件的流水账记录如下：
1. 任务 A 呼叫SVC 来请求任务切换（例如，等待某些工作完成）
2. OS 接收到请求，做好上下文切换的准备，并且pend 一个PendSV 异常。
3. 当 CPU 退出SVC 后，它立即进入PendSV，从而执行上下文切换。
4. 当 PendSV 执行完毕后，将返回到任务B，同时进入线程模式。
5. 发生了一个中断，并且中断服务程序开始执行
6. 在 ISR 执行过程中，发生SysTick 异常，并且抢占了该ISR。
7. OS 执行必要的操作，然后pend 起PendSV 异常以作好上下文切换的准备。
8. 当 SysTick 退出后，回到先前被抢占的ISR 中，ISR 继续执行
9. ISR 执行完毕并退出后，PendSV 服务例程开始执行，并且在里面执行上下文切换
10. 当 PendSV 执行完毕后，回到任务A，同时系统再次进入线程模式。
详见Cortex-M3权威指南124页。

注，这里我想说明的是根据图7.16我的个人推论，可能是错误的，在linux中每一个用户空间的进程都有自己的用户栈，和核心栈，如果cortex-m3结合rt-thread也是用这个模式，可以印证图7.16，当IRQ执行的过程中，Systick异常发生， IRQ的执行上下文现场被保存在任务A的核心栈中，然后执行上下文切换，上下文切换完成后，寄存器MSP和PSP分别指向了任务B的核心栈指针和用户栈指针，然后IRQ随着任务A被封存而封存，任务B压根不知道任务A的栈中还封存着一个IRQ，因为任务B及时有权限不应该去破话另一个任务的栈空间。直到任务A重新得到CPU，IRQ接着在任务A的栈空间继续执行，可惜从中断产生到中断服务程序结束，已经隔了十万八千年。

经过实际验证，Cortex m3结合rt-thread 应该没有使用和linux一样的模型，而是所有的线程共享内核栈，即MSP 执行的栈空间所有线程共享，这里和linux-arm有个小区别，linux-arm 中断来临的时候，保存现场都是保存在内核栈中，这个内核栈是每一个内核线程独有的，而 Cortex-m3--rtthread 是中断来临之前使用用户栈（PSP寄存器所指的栈空间），保护现场就在用户栈，中断来临之前使用核心栈（MSP寄存器所指），保护现场就用核心栈，但由于PendSV悬起中断的引入，所以线程切换的都借助PendSV来完成，这就保证线程切换的PendSV来临之前保护现场，一定在用户栈，用户栈是每个线程所独有的，所以，综上所述，针对线程切换所对应的中断， linux-arm保存现场都是在核心栈，而cortex-rtthread都是在用户栈，但是他们都能保证，保存现场所用的空间是每一个内核线程独有的。