You copied the Doc URL to your clipboard.

AIRCR.PRIS behavior in Cortex-M33

Article ID: 183875327

Published date: 10 Apr 2018

Last updated: -

Applies to: Cortex-M33


How does AIRCR.PRIS work in Cortex-M33?


This knowledge article is relevant to chip designers of chips containing a Cortex-M33 processor that includes the Security Extension, and to programmers writing the Non-Secure software configuration code for such chips.

The Armv8-M Architecture Reference Manual describes a priority scheme that is similar to the scheme in Armv7-M, based on a theoretical 8-bit priority program that is split into two parts by the programming of the PRIGROUP bit field in the Application Interrupt and Reset Control Register, AIRCR.PRIGROUP. Between 0 and 7 most significant bits comprise the GROUP, or preempting priority, while the remaining 1 to 8 bits comprise the non-preempting SUBPRIORITY field.

A specific instance of a processor might be configured to implement fewer than 8 of these bits, in which case the more significant bits are implemented, and the less significant bits are zero.

The Armv8-M Architecture also introduces a Security Extension. When the Security Extension is implemented, the AIRCR.PRIS bit can be set by Secure software to deprioritize Non-Secure interrupts in the manner illustrated under information statement IXFVH by shifting the Non-Secure GROUP priority one place to the right, with a '1' shifted into the most significant bit.

In some editions of the Armv8-M Architecture Reference Manual, this information statement is slightly inconsistent regarding whether the least significant bit is retained (as in mapping 0x02 to 0x81) or dropped (as in mapping 0xFE to 0xFE).

The Armv8-M Architecture Reference Manual does not describe the interaction of the AIRCR.PRIS function with the implementation defined reduction of the number of physically implemented priority bits in an individual processor configuration.


Cortex-M33 (Teal) allows the chip designer to configure between 3 and 8 most significant bits physically implemented in the priority scheme, by setting the IRQLVL parameter. This limits the implemented width of the NVIC_IPRn registers themselves, and the width of the prioritization logic trees that compare them.

For functional and timing reasons, the priority decision trees are broken down into different sub-trees, and then the highest priority results from each sub-tree are compared.

At the time of writing this article, the current release version of Cortex-M33 is r0p3.

In the current and previous versions of Cortex-M33, the comparisons between sub-tree results to calculate the overall highest priority pending interrupt are limited by the IRQLVL setting.

When PRIS is set, and two Non-Secure interrupts are pending, the priority order can be affected by whether the interrupts belong to the same sub-tree or to different sub-trees. Interrupts in the same sub-tree observe the full GROUP priority order, as the prioritization within the sub-tree is resolved before the PRIS function is applied. Interrupts in different sub-trees might discard one least significant bit of the GROUP priority if the PRIS function shifts this l.s.b. off the end of the IRQLVL range, because the PRIS function is applied before comparing the GROUP priorities between the different sub-trees.

In this case, where GROUP priority occupies the full IRQLVL number of implemented bits and AIRCR.PRIS is set, two Non-Secure interrupts whose programmed priorities differ only in the least significant bit of IRQLVL might be considered to have equal GROUP priority, and since there are no available subpriority bits, the prioritization decision will be dependent only upon the exception number order.


If a chip implements the Security Extension, and it is intended that the Non-secure user should be provided with the ability to rely upon having 'N' bits of GROUP priority available in the Non-Secure space even if Secure software sets the AIRCR.PRIS bit, then the chip designer should select a hardware configuration with IRQLVL = (N + 1).


IRQLVL is configured at 3. This implies that the NVIC_IPR registers and the priority logic are implemented in only the three most significant bit positions.

Secure software has set the AIRCR.PRIS bit to '1' to deprioritize Non-Secure interrupts relative to Secure interrupts.

AIRCR_NS.PRIGROUP is set to 4 or less, meaning that all implemented bits of Non-Secure priority are GROUP priority bits.

Non-Secure interrupt 'A' has a programmed priority of 0x20.

Non-Secure interrupt 'B' has a programmed priority of 0x00.

If interrupts 'A' and 'B' are pending at the same time, the processor most likely prioritizes interrupt 'B' over interrupt 'A'; but if these interrupts happen to be mapped in different sub-trees of the priority logic, and interrupt 'A' has a lower interrupt number than interrupt 'B', then the processor might prioritize interrupt 'A' over interrupt 'B'.

If the workaround of setting IRQLVL to 4 instead of 3 in the chip configuration is implemented, then these interrupts 'A' and 'B' will always be prioritized in the intended order.

Related Information


Was this page helpful? Yes No