Clarity Around Interrupt Priorities

RE: Clarity Around Interrupt Priorities

hmolesworth — Tue, 07 Nov 2023 19:52:06 GMT

Your assumption is quite correct; an active level 5 interrupt service routine will be interrupted by an exception linked to an enabled level 4 interrupt.

This example considers three exceptions with configurable priority:
• A has highest priority, described as priority A.
• B has medium priority, described as priority B.
• C has lowest priority, described as priority C.
Consider the following sequence of events:
1. Exception B occurs. The processor takes the exception and starts executing the handler for this exception.
The execution priority is priority B.
2. Exception A occurs. Because its priority is higher than the execution priority, it preempts exception B and the processor starts executing the Exception A handler. Execution priority is now priority A.
3. Exception C occurs. Its priority is less than the execution priority so its status is pending.
4. The handler for exception A reduces the priority of exception A, to a priority lower than priority C. The execution priority falls to the highest priority of all active exceptions. This is priority B.
Exception C remains pending because its priority is lower than the current execution priority. Only a pending exception with higher priority than priority B can preempt the current exception handler.
Therefore, a new exception with lower priority than exception B cannot take precedence over the preempted exception B.

https://developer.arm.com/documentation/ddi0403/latest/

RE: Clarity Around Interrupt Priorities

snoopy20 — Tue, 07 Nov 2023 10:48:57 GMT

Great explanation thanks, that's a Cortex feature I hadn't came across yet. I assumed there was some memory identifiers buried within a config file within the sdk. Assumptions eh!

There was no benefit to having the scheduler interrupt calls serviced outside the interrupt other than to run at the lowest priority and it added a little overhead checking the event flags. I did however make another assumption and that is an interrupt at priority 4 would literally interrupt an interrupt at priority 5 and then jump back in afterwards. Reading up I'm unsure now if this is the case, or whether a queue develops and when it comes to servicing it the highest priority is chosen first.

I can't recall now why the scheduler was higher priority but I just tried it at 7 and it works the same. I think at the time I expected the ADC looping to hit it (there's some computational work being done inside the interrupt).

RE: Clarity Around Interrupt Priorities

ovrebekk — Tue, 07 Nov 2023 09:06:38 GMT

Hi Andrew

All the SoftDevice functions are using so called SVC function calls (also called supervisor calls), and will run in a software interrupt at interrupt level 4 as shown here.

The SVC mechanism associates each function call with a unique 8-bit number, and executes the function itself from an interrupt.

An advantage of this is that the application doesn't need to know where the various functions are located in the SoftDevice, it only needs to be able to trigger the SVC mechanism. This is what makes it possible to compile and link your application completely independently of the SoftDevice, and is a critical aspect of the SoftDevice architecture.

The drawback of this method is that if you try to call a SoftDevice function from an interrupt at level 4 or higher the SVC call will be blocked by the code calling it, and your application will crash.

Running a scheduler from interrupt context seems a bit odd. How much time do you expect to spend running the scheduler?
And if you are to do this wouldn't it make more sense to assign the lowest interrupt priority (7) to the scheduler, so that other interrupts can supersede it?

Best regards
Torbjørn

RE: Clarity Around Interrupt Priorities

snoopy20 — Mon, 06 Nov 2023 10:45:47 GMT

No this is a home brew scheduler. That explains why I have to run it at priority 5, so it seems the priorities are also acting as a security 'firewall' of sorts.

It would be good to understand this a little more, like the calls themselves are just jumps with nothing to do with priorities? I don't see how they can be restricted to only operate by callers operating at a particular priority level?

RE: Clarity Around Interrupt Priorities

ovrebekk — Mon, 06 Nov 2023 10:16:05 GMT

Hi Andrew

By scheduler do you mean the app_scheduler library?

Are you running the app_sched_execute() function from an interrupt?

The idea behind this library is to schedule execution from the main context, and usually app_sched_execute() is simply called from the main loop before entering sleep. Then you can safely schedule callbacks from any interrupt context, and have it executed from the main context once all interrupts are finished.

Running this from an interrupt is not tested, and I am not sure how well this will work.

Any code that makes calls into the SoftDevice will need to run at priority 5 or lower (higher number), otherwise it won't work.

Best regards
Torbjørn