Hello, I meet a problem while using Spin Model Checker to verify a RTOS kernel based on Cortex-m3 platform.
My PendSV is in the lowest priority 16 and perform to schedule next user task and context switch. While PendSV is executing, another exception with same priority 16 comes in. The exception will be in pending state due to the same priority of PendSV. Meanwhile, the PendSV has the higher exception number than the pending exception and the subpriority group is not been set.
Due to the rule of priority group, the later exception will be pending while it has the same priority with current exception and executes after the exception return of the current exception. However, the PendSV is performing the context switch, the user task may not be the same after the exception return. In this situation, the exception will preempt the new user task, but it was occurred while the previous user task was executing.
Or, the exception will preempt PendSV immediately but the PendSV has a higher exception number? I am not sure which situation mention above is true or non of the situations are true?
I believe first situation is close due to the documentations, but the exception occured in previous user task can preempt new user task is confusing me a long time.
kaizsv
Yes, the first situation is correct. The interrupt will tail chain after PendSV.
Interrupt events (excluding SVC and synchronous fault exceptions) are considered "asynchronous" so in general you cannot guarantee the IRQ handler to take place at particular time. Especially other interrupt events (which trigger other handler executions) can also delay the interrupt service. As a result, even if an interrupt event take place in context X inside your RTOS, you cannot guarantee the handler to execute within context X.
SVC and synchronous fault events are different from IRQ handling. In the case of a user task X executed an SVC just before context switch, the SVC service will execute before the PendSV and it will see the context X in the process stack, so it can provide services to the correct context. The same applies to synchronous fault event handling.
Regarding asynchronous fault event (bus error response in a bufferable write), from architectural point of view it is possible for the fault handler to be started in a different context. But in the case for Cortex-M3, because exceptions cannot start until all outstanding data access is completed, you will have the fault handler execution in the same context.
Hope this helps.
regards,
Joseph
Thanks for your reply, it has been a great helps.