CM33 port and NonSecure interrupt de-prioritization

Kernel
1

Hi,

I am currently trying the FreeRTOS port on a Cortex-M33 architecture with the TZ being activated and the FreeRTOS kernel being in NonSecure.

At the start of the scheduler, the function “SecureInit_DePrioritizeNSExceptions” is called, with the comment associated being “De-prioritize the non-secure exceptions so that the non-secure pendSV runs at the lowest priority”.
In the different port (portable/gcc/ARM_CM33/secure/secure_init.c for example), this function is effectively executed by setting the PRIS bit of the AIRCR register. Which prioritize part of the Secure interrupt.

I understand that PendSV needs to run at the lowest priority, but why is this function necessary ?

It is still possible to run the PendSV interrupt at the lowest priority without calling SecureInit_DePrioritizeNSExceptions by being sure that Secure and NonSecure interrupt have higher priority than the NonSecure PendSV ?

Furthermore, forcing this configuration (PRIS set in AIRCR), will have impact on the user application as users NonSecure IRQ will also be de-prioritized.

Do you have information on why this function has been introduced ? And will it be OK to leave the implementation of this function blank (so without setting PRIS bit in AIRCR) and ensuring that PendSV has the lowest priority of all the S/NS interrupt by correctly setting it in the final application ?

Thank you for your help,

Regards,

Romain

2

Yes, that should work.

Yes, it ensures that secure interrupts run at the higher priority.

Yes, that should be fine. What problem are you trying to solve though?

3

Hi,

Thank you for your quick answer.

I want to have a configuration where I could have FreeRTOS running with NonSecure interrupt having a higher priority of Secure interrupt (so without necessary having PRIS bit of AIRCR set).

This could be of interest when you want low latency IRQ in the NonSecure (for example for real time communication) while still having IRQ in the Secure part which can’t preempt your NS IRQ and everything with FreeRTOS running.

So I could still go for the configuration AIRCR.PRIS=0 I talked about.

But when you take a look at the cortex-m33 reference manual, AIRCR.PRIS bit set doesn’t prevent Secure IRQ to have lower priority than NonSecure IRQ, it only ensures that priority of Secure interrupt with priority value lower that 0x80 will not be preempted by NonSecure interrupt.

image

So I am not sure that having AIRCR.PRIS=1 is necessary as you still have to pay attention to your S/NS IRQ priority.

Regards,

Romain

4

Just for clarity, are you trying to do something that requires PRIS=0?

PRIS=1 isn’t necessary for proper FreeRTOS operation but it seems a good standard to enforce.

5

Yes I want my application with PRIS=0

I wanted to be sure that PRIS=1 was not a prerequisite for FreeRTOS port as the code and comment could suggest.

Depending on the threat model and the real-time needs PRIS=1 is not necessarily the best fit for the application.

Thanks for your answers,

Regards,

Romain