Is it possible to set NVIC priority group of nRF9160?

[Jayant Tang]

Hello DevZone,

One customer used Timer+PPI+GPIOTE to simulate an UART. Now it works fine.

However, when there is other timer's interrupt, the simulated UART may lose some bits.

So we want to change the NVIC priority group.

Since there is no NVIC description in datasheet, we have to read the SDK initialization code. Now we know that in `SystemInit()` it don't set SCB->AIRCR or call `NVIC_SetPriorityGrouping()`.

We want to know if we can set the NVIC Priority Group in `nrf9160/ns`. 

If we can, does this affect the interaction with modem?

Best regards,

Jayant

[Øyvind]

Hello Jayant, 

I will look into your ticket. Will need to discuss with our nRF91 experts. From what I can see, the information on the Nested Vector Interrupt Controller for the nRF91-series is described in the Arm Cortex M33 Technical Reference Manual.

Kind regards,
Øyvind

[tinyk.hu]

Hello DevZone：

I'm ther customer.

Below is the background information for our project.

timer0 IRQ 15 used for simulate uart rx
timer1 IRQ 16 used for simulate uart tx
timer2 IRQ 17 used for simulate I2C

define CONFIG_ZERO_LATENCY_LEVELS=2 in prj.conf

timer0 timer1 timer2 int DTS as follows can work ok

timer0 {
status = "okay";
zli;
prescaler = <0>;
interrupts = <15 0>;
};

timer1{
status = "okay";
zli;
prescaler = <0>;
interrupts = <16 0>;
};

timer2 {
status = "okay";
zli;
prescaler = <5>;
interrupts = <17 2>;
};

when I change timer2 int DTS as follows cannot work ok

timer2 {
status = "okay";
zli;
prescaler = <5>;
interrupts = <17 1>;
};

I printed the priority-grouping value and the priority values of the enabled interrupts.

get the priority-grouping value with NVIC_GetPriorityGrouping

get the IRQn priority value with NVIC_GetPriority

when timer2 interrupts = <17 1> the priority-grouping value and the priority values as follows:

PriorityGroup:0x0
IRQ 5 Priority:0x7 the Priority register value is 0xe0
IRQ 8 Priority:0x7 the Priority register value is 0xe0
IRQ 9 Priority:0x7 the Priority register value is 0xe0
IRQ 10 Priority:0x7 the Priority register value is 0xe0
IRQ 11 Priority:0x7 the Priority register value is 0xe0
IRQ 14 Priority:0x7 the Priority register value is 0xe0
IRQ 15 Priority:0x0 the Priority register value is 0x00
IRQ 16 Priority:0x0 the Priority register value is 0x00
IRQ 17 Priority:0x1 the Priority register value is 0x20
IRQ 21 Priority:0x7 the Priority register value is 0xe0
IRQ 24 Priority:0x7 the Priority register value is 0xe0
IRQ 42 Priority:0x7 the Priority register value is 0xe0
IRQ 49 Priority:0x7 the Priority register value is 0xe0

when timer2 interrupts = <17 2> the priority-grouping value and the priority values as follows:

PriorityGroup:0x0
IRQ 5 Priority:0x7 the Priority register value is 0xe0
IRQ 8 Priority:0x7 the Priority register value is 0xe0
IRQ 9 Priority:0x7 the Priority register value is 0xe0
IRQ 10 Priority:0x7 the Priority register value is 0xe0
IRQ 11 Priority:0x7 the Priority register value is 0xe0
IRQ 14 Priority:0x7 the Priority register value is 0xe0
IRQ 15 Priority:0x0 the Priority register value is 0x00
IRQ 16 Priority:0x0 the Priority register value is 0x00
IRQ 17 Priority:0x2 the Priority register value is 0x40
IRQ 21 Priority:0x7 the Priority register value is 0xe0
IRQ 24 Priority:0x7 the Priority register value is 0xe0
IRQ 42 Priority:0x7 the Priority register value is 0xe0
IRQ 49 Priority:0x7 the Priority register value is 0xe0

I ran a test:
when Timer2’s interrupt priority is set to 1, Timer0 and Timer1 interrupts cannot preempt Timer2’s ISR;
when Timer2’s priority is changed to 2, Timer0 and Timer1 can successfully preempt it.

my question:
as we know nrf9160 Number of Bits used for Priority Levels is 3

#define __NVIC_PRIO_BITS 3 /*!< Number of Bits used for Priority Levels

when PriorityGroup value set 0, is the 3 Bits used 2Bits for group priority and 1Bit for subpriority or 3Bits for group priority and 0Bit for subpriority

[Øyvind]

Thanks for providing this information. I will add this to the internal discussion.

Kind regards,
Øyvind

[tinyk.hu]

Hello DevZone：

          Any progress on the case?

[Øyvind]

Hello, 

Unfortunately not. The question has been escalated internally. I hope to have an answer by end of Monday (Central European Time).

KInd regards,
Øyvind

[Øyvind]

Hello, and thanks for your patience with this matter. 

Here are the answers i received:

First, based on our findings for CM33 in nRF9160:

• There is indeed only three priority bits available.

• The thee bits are treated as “gg.s” i.e. two upper bits for group priority, lowest bit for sub-priority.

• Ref ARM v8-M Exception Model User Guide, exception priority level definitions: Armv8-M Exception Model User Guide - Priority grouping

Second, from ARM CM33 documents:

• CM33 “URGM” : Documentation – Arm Developer - Interrupt priority grouping , Exception model:

Interrupt priority grouping

To increase priority control in systems with interrupts, the NVIC supports priority grouping. This divides each interrupt priority register entry into two fields, an upper field that defines the group priority, and a lower field that defines a subpriority within the group.

Only the group priority determines pre-emption of interrupt exceptions. When the processor is executing an interrupt exception handler, another interrupt with the same group priority as the interrupt being handled does not pre-empt the handler.

If multiple pending interrupts have the same group priority, the subpriority field determines the order in which they are processed. If multiple pending interrupts have the same group priority and subpriority, the interrupt with the lowest IRQ number is processed first.

If a pending Secure exception and a pending Non-secure exception both have the same group priority field value, the same subpriority field value, and the same exception number, the Secure exception takes precedence.

 

Also, in ARM v8-M Architecture specification:

• Exception handling:

  • “When a pending exception has a lower group priority value than current execution, including accounting for any
    priority adjustment by AIRCR.PRIS, the pending exception preempts current execution.“

tinyk.hu said:

when Timer2’s interrupt priority is set to 1, Timer0 and Timer1 interrupts cannot preempt Timer2’s ISR;

It matches as then Timer2 has the same gruop priority as other Timer ints = no pre-emption.

tinyk.hu said:

when Timer2’s priority is changed to 2, Timer0 and Timer1 can successfully preempt it.

It matches as then Timer2 has lower group priority (higher group priority value) as other Timer ints = pre-emption happens.

Let us know if this answers your questions, or if you have any further questions.

Kind regards,
Øyvind

[tinyk.hu]

Hello DevZone:

           Thank you for your reply.

     The thee bits are treated as “gg.s” i.e. two upper bits for group priority, lowest bit for sub-priority  Consistent with my measured results. 

However, I still have a question. According to the definition of interrupt grouping, only when the AIRCR.PRIS value is 3'b101 does it correspond to gg . ssssss format. The currently read AIRCR.PRIS value is 0x0, which corresponds to ggggggg . s format (Group priority . Subpriority).

Can the CM33 modify this interrupt grouping bits definition?

[Øyvind]

Hello, there is the feedback I got:

AIRCR.PRIGOUP (so, not PRIS) reset value and default setting in the CM33 is 3’b000, which indeed aligns what customer is seeing.

If customer can read back that AIRCR.PRIGOUP 3’b000 at run-time it indicates it has not been overwritten to something else by SDK either. But, yes, basically system SW could change that value to something else.

Kind regards,
Øyvind

[tinyk.hu]

Hello DevZone:

      yes,It is AIRCR.PRIGOUP.  

• The thee bits are treated as “gg.s” i.e. two upper bits for group priority, lowest bit for sub-priority.

  if the  AIRCR.PRIGOUP value is 0,which corresponds to ggggggg . s format (Group priority . Subpriority).  and the thee bits treated as ggg0000.0 ,the thee bits are all for group priority

 I ran a test:
when Timer2’s interrupt priority is set to 1, Timer0 and Timer1 interrupts cannot preempt Timer2’s ISR;
when Timer2’s priority is changed to 2, Timer0 and Timer1 can successfully preempt it.

In the tests above, all the AIRCR.PRIGOUP values read were 0x0.  According to the CM33's preemption definition, the priority grouping for Timer1 and Timer2 is different under these two configurations, allowing for preemption.