NVIC priority grouping

Posted on May 17, 2011 at 12:36

Hello All,

I am wondering how the NVIC priority grouping works ?

In the ARM reference manual there are 7 PRIGROUPs,

but if using the ST NVIC firmware library you only have the possibility to use four different groups.

Now i have choosen PRIGROUP 4, which should give me 4 bits for preemption priority and 4 bits for sub-priority.

/* Configure four bit for preemption priority */

NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);

However in the library it states that NVIC_PriorityGroup_4

gives you 4 bits for pre-emption priority and 0 bits for subpriority

Trying to execute the following setup gives me the right preemption value

but sub-priority is set to 0 (analyzing the NVIC_Init function explains why !)

/* enabling CAN RX0 interrupt */

NVIC_InitStructure.NVIC_IRQChannel=USB_LP_CAN_RX0_IRQChannel;

NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 14;

NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;

NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

NVIC_Init(&NVIC_InitStructure);

But why the deviance in the library compared to the ARM spec. ??

Anyone have an opinion ?

BR

Brian

Posted on May 17, 2011 at 12:36

Hi Brian,

Have a look in RM0008 from ST :

8 Interrupts and events

8.1

â—� 16 programmable priority levels (4 bits of interrupt priority are used)

B.Regards,

Asterix.

Posted on May 17, 2011 at 12:36

Thanks guys !

Your comments cleared things for me :)

br

Brian

Posted on May 17, 2011 at 12:36

In the STM32 only the 4 most significant bits in PRIMASK are implemented, the ARM specification does not mandate the implementation of all the bits. The priority can be organized in one of the following modes:

PRIGROUP

3 - 4.0

4 - 3.1

5 - 2.2

6 - 1.3

7 - 0.4

You usually don't need to have sub priorities unless you application has some peculiar requirements (as example in order to limit the main stack growth), you can just use the 4.0 organization.

regards,

Giovanni

Posted on May 17, 2011 at 12:36

hi brj,

there's no discrepancy, the cortex core is configurable. the implementer (ST) chooses values for the configurable parameters, thus instantiating a specific implementation of the core. (the implementer chooses the complexity and thus the cost.)

the cortex manual says that the number of bits that encode the priority in all cortex implementations must fall within a specific range (which I don't remember now). ST's docs say that in the STM32 priorities are encoded with 4 bits.

in the case you mention, the lib docs are correct: if you use 4 bits for preemption, there will be zero left for subpriority.