After further analysis, I found this to be true:
If the secure interrupt has a priority lower than the secure pendsv interrupt, then the associated SP code will run in thread mode at the exception priority level of the secure interrupt.
If the priority of the secure interrupt is equal to or greater than the secure pendsv interrupt then associated the SP code will run in thread mode with NO exception priority level.
Alan -----Original Message----- From: DeMars, Alan Sent: Tuesday, October 29, 2019 8:54 AM To: 'Mate Toth-Pal' Cc: 'tf-m@lists.trustedfirmware.org' Subject: RE: SP thread priority when servicing secure interrupts
Mate,
I'm using the IPC model. My secure interrupt has priority 0xe0, whereas the pendSV interrupt has priority 0x60.
I'll attempt to provide a procedure for reproducing my results.
In the meantime, is there a doubt-free way to determine the execution priority while the processor is in thread mode?
Alan
-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, October 29, 2019 5:50 AM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SP thread priority when servicing secure interrupts
Hi Alan,
The expected behaviour depends on the Model used in the TF-M.
Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active.
IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again.
If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour?
Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well.
Thanks, Mate
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m@lists.trustedfirmware.org' tf-m@lists.trustedfirmware.org Subject: [TF-M] SP thread priority when servicing secure interrupts
It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt.
While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns.
Is this true and expected behavior?
Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode.
Alan