PendSV中断嵌套问题

dg00010170

PendSV中断嵌套问题 [复制链接]

请教版主几个STM32关于中断的问题：
  1  所谓的“晚到的高优先级中断/异常处理”，是否只有在已经开始相应低级中断取向量之前（更新寄存器SP、xPSR、LR等应在取向量之后吧）晚到的高优先级异常/中断才能抢占利用正在处理的低优先级异常/中断的入栈操作，只要已经发生了取向量，就必须按嵌套的高优先级异常/中断处理（至少要等到低优先级的执行ISR的第1条指令后才发生嵌套）？
  2  关于PendSV，当正执行PendSV的ISR时（如OS的任务切换时），发生了高优先级的异常/中断，高优先级异常/中断ISR处理中又挂起了PendSV（置位ICSR的PendSVSet位〈0xE000_ED04.bit28〉)时(即高优先级的异常/中断出发了OS的任务切换),高优先级异常/中断挂起的PenSV是否作为一个新的PendSV请求,而当高优先级的ISR处理完后返回继续处理先前被中断的PenSV的ISR,处理完被中断的PenSV后再以中断尾链的方式在一次响应在高优先级异常/中断中挂起的PenSV(响应高优先级异常/中断的要求的任务切换)?

lovertian

1.这种情况属于lata-arriving，CM3的参考手册上有比较详细的描述，被抢占的低优先级ISR的第一条指令如果没有进入执行阶段(CM3三级流水线中的第三阶段)，被高优先级中断抢占就属于lata-arriving，后来的中断不会再进行寄存器自动入栈。
2. 理论上OS任务切换时是要关中断的，关了中断就不会被高优先级中断抢占了。假设PendSV的ISR没有关中断，我觉得楼主描述的过程应该是对的，手册上貌似没有说明这种情况，但我个人理解，ICSR的PendSVSet位是在进入PendSV的ISR后硬件清除的，这时如果PendSV的ISR被抢占并在高优先级的ISR中PendSVSet又被置位，应该是有效果的，就是说，执行完旧的PendSV还要再执行一次新的PendSV。 只是推测，楼主可以做实验试试。

hbxgyjs

                                 OS任务切换肯定是要关中断的

feichong

谢谢各位！只是我觉得按CM3手册《李岩 ARM CM3 权威指南》，CM3在中断响应过程，第一步入栈板保存现场，然后更新各寄存器（包括PC），然后再开始执行ISR，我的疑惑是在更新了部分或全部寄存器而在开始执行ISR前来了更高优先级中断，那么已经更新寄存器全部丢弃，按Late-arriving处理，之后再按tail-chaining处理？抑或按嵌套的中断处理？
  对于2，我的疑惑是，利用PendSV的自动入栈和出栈操作，按楼上说的，OS任务切换关中断应该在挂起PenSV之前，否则若在PendSV中关中断，则需要在PendSV的ISR返回前开中断，而开了中断就有可能被高级中断抢占（假设PendSV为最低优先级）,而这样就使PendSV的ISR中任务切换时只是部分还原了任务现场(R4~R11),其他8个寄存器因还没有执行PendSV的返回而没有还原了就有被中断了;但若是在响应PendSV前关中断,那就不可能响应PendSV了.
   另外,还有个疑惑,我觉得按CM3手册《李岩 ARM CM3 权威指南》，CM3设计初衷,其中的非特权模式(Unprivileged)使用于用户任务,PendSV用于OS的任务切换,那么就有二个问题:a 在Unprivileged模式下不能执行MRS/MSR以及CPS指令,也就是说在用户任务中不能开关中断,那么采用类似于uCos II的OS中CM3就不能运行在Unprivileged模式下,否则uCos II中的各种系统调用都不能用(不会建议用SVC切换CM3
特权模式再开关中断吧?);b NVIC的寄存器不能在Unprivileged模式下操作,那么也就不能关起PendSV了,难道也先要切换到Privileged模式再挂起PendSV? 基于以上CM3若在Unprivileged模式下开放CPS指令和挂起PendSV,uCos II就可以完美的利用CM3的Unprivileged模式下的安全保护特性了.

kyj17096

对于2，我的疑惑是，利用PendSV的自动入栈和出栈操作，按楼上说的，OS任务切换关中断应该在挂起PenSV之前，否则若在PendSV中关中断，则需要在PendSV的ISR返回前开中断，而开了中断就有可能被高级中断抢占（假设PendSV为最低优先级）,而这样就使PendSV的ISR中任务切换时只是部分还原了任务现场(R4~R11),其他8个寄存器因还没有执行PendSV的返回而没有还原了就有被中断了;但若是在响应PendSV前关中断,那就不可能响应PendSV了.

这个时候再来更高优先级的中断只能当做嵌套中断来处理，走嵌套中断的正常流程(完整的入栈出栈顺序)，既然是走正常流程，那就不会有其余8个寄存器因不执行PendSV返回而无法还原的情况了。走嵌套中断流程的原因：PendSV的代码已经执行，不能当作晚到来处理。新中断优先级高于PendSV，不会走咬尾流程(实际咬尾对这种情况没有影响)。其实说到这里我觉得楼主多虑了，作为一个芯片的设计者，这些新的设计(咬尾与晚到)应该是“优超”老的设计(只有中断嵌套)，即在保证逻辑一致的情况下提供更好的性能。

sgyao

另外,还有个疑惑,我觉得按CM3手册《李岩 ARM CM3 权威指南》，CM3设计初衷,其中的非特权模式(Unprivileged)使用于用户任务,PendSV用于OS的任务切换,那么就有二个问题:
a 在Unprivileged模式下不能执行MRS/MSR以及CPS指令,也就是说在用户任务中不能开关中断,那么采用类似于uCos II的OS中CM3就不能运行在Unprivileged模式下,否则uCos II中的各种系统调用都不能用(不会建议用SVC切换CM3
特权模式再开关中断吧?);
b NVIC的寄存器不能在Unprivileged模式下操作,那么也就不能关起PendSV了,难道也先要切换到Privileged模式再挂起PendSV? 基于以上CM3若在Unprivileged模式下开放CPS指令和挂起PendSV,uCos II就可以完美的利用CM3的Unprivileged模式下的安全保护特性了.

a: 确实是要用SVC来开关中断
b: 是需要切换到Privileged模式
实际上当在OS中需要关中断或是挂起PendSV的时候，也会伴随着内核资源的修改与访问，是应该切换至Privileged模式

leuliu

第一个问题，建议看CM3的官方参考手册，权威指南上这部分好像没有说清楚。是否按late-arriving处理，判断标准就是看较早发生的中断的第一条指令是否进入了执行阶段，如果进入了就按抢占处理，没有进入执行阶段(可能处于取指或译码阶段)就按late-arriving处理。至于寄存器更新，个人觉得作为芯片的使用者没有必要太关心它的时序，芯片的设计者肯定会想办法避免late-arriving的中断使用上一个中断更新的寄存器值。不要把寄存器更新看做是否按late-arriving处理的标准就可以了。

第二个问题，实在看不出“其他8个寄存器因还没有执行PendSV的返回而没有还原了就有被中断了”会对实际应用有什么影响，那8个寄存器是在堆栈里的，tail-chain执行新的PendSV返回之后还是会恢复它们的。

特权模式的问题，UCOSII的CM3官方移植版本，都是按用户程序处于privileged模式来编写的，即用户程序是可以开关中断和挂起PendSV的。如果一定要使用户程序工作在非特权模式，可能就比较麻烦了。最起码，在用SVC关了中断之后不能再切回Unprivileged，因为CM3内核关中断之后就不响应SVC了，连时钟节拍也没了，而且还打不开中断，死路一条了。

arcsink

                                 LS解释的比较详细，支持下，不过读了一遍，不是很明白意思

zhp3245

                                 学习一下！