With a support entitlement you can also get direct access to our team of highly-qualified Arm experts 24-hours a day
Open a support case
I was wondering if it was possible to configure a peripheral to be in non-secure mode and have the interrupt handler associated with the peripheral run in secure mode?
Basically by not setting the appropriate bit in NVIC_ITNSn.
It is technically possible to configure a peripheral as Non-secure and its interrupt as Secure, but in some cases this might be undesirable - e.g. a Non-secure software could trigger lots of Secure interrupt and this might affect the quality of service of other Secure operations. Or in other way round, a Secure software process might be waiting for an interrupt for the peripheral and the Non-secure software disabled the peripheral, which means the Secure software process would be stuck. Whether this is a problem or not depending on the nature of the peripheral.
Thank you Joseph.
A related question regarding secure interrupts.
Suppose we enter a secure interrupt from non-secure unprivileged thread mode, after the ISR is done, it is possible to return to non-secure privileged thread mode by appropriately setting EXC_RETURN. Correct?
I am still learning about ARMv8-M/TrustZone, so please bear with me if I am asking basic questions. Thank you once again!
Changing the value in EXC_RETURN.Mode shall only make the interrupt handler to exit to Thread or Handler mode.
CONTROL.nPRIV (banked between states) decides the privilege of execution.
Assuming that your CONTROL_NS.nPRIV before entering the secure interrupt handler is marked as 'Unprivileged', then changing CONTROL_NS.nPRIV to 'Privileged' in secure interrupt handler means that there is a mismatch in stacking and unstacking process attribute. This is because, on exception entry, the stacking process will marked with unprivileged access while on exception exit, the unstacking process will be marked with privileged access.
Thank you for your reply.
That's correct. Sorry I forgot to mention about CONTROL.nPRIV.
Yes, within the interrupt handler, besides changing the EXC_RETURN.Mode, I would also need to do something like -
mov r0, #0
msr control_ns, r0
Before doing a bx lr.
This should get me back to non-secure privileged thread with MSP_NS. Isn't it?
There is no need to change the CONTROL and EXC_RETURN if the mode and state before and after the ISR are the same. The EXC_RETURN has been extended to support additional information about security states, so all the Secure ISR can be implemented as normal C function.