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

[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.

[Jayant Tang]

Hi tubyjk,

Let me summarize:

1. AIRCR.GROUP=0 means the format is ggggggg.s 

2. There are only 3 priority bits for nrf9160. So that format will be "gg.s". And this accord with what you tested on Timer.

And I got your question:

Wen you set priority value b00000010, in this function it will be convert to b01000000

But the default value of AIRCR.PRIGROUP is 0. You think this could become b0100000.0

This "bit-shift" seems not be mentioned in Cortex-M33 specification. Øyvind  Do you have any idea about this?

[Øyvind]

Hello, I have forwarded to our experts. I did so for the last comment, but did no get an answer, will retry with your comments Jayant Tang . 

[Øyvind]

Hello, just an update from our side. Our team have forwarded to ARM support to verify functionality.

Will update as soon as we have more feedback to you.

Kind regards,
Øyvind

[Øyvind]

Hello Jayant Tang and tinyk.hu 
thanks for your patience on this matter.

Our team informs me that ARM Support confirms how the IRQ priority bits, three in our case, are being treated as group (preemptive) and sub-priority, based on the AIRCR.PRIGOUP setting. Image summary table below. From here, the first row, we can then gather that with PRIRGOUP at default value '0' all three bits are used as group priority bits.

Based on this, our team were not able to map earlier findings matching the expected behavior:

“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.”

Instead, in both cases with Timer2 IRQ priority set to a non-zero value (= group priority set lower vs. Timer0 and Timer1) the Timer0 and Timer1 IRQs should be able to preempt it.

Another thing that would impact here is the AIRCR.PRIS setting: if this set on (high) then any secure IRQs would have higher priority over non-secure IRQs.

Can you please check AIRCR.PRIS setting, if set how are the sec/non-sec configs between Timer0/Timer1/Timer2?

Kind regards,
Øyvind

[tinyk.hu]

thank you very much

[Jayant Tang]

Hello,

The customer's test result is not same as the table you provide. That's why map the earlier findings.

Øyvind said:

Based on this, our team were not able to map earlier findings matching the expected behavior:

For the customer's test, when AIRCR.PRIGOUP from 0 to 5, the priority bits should always be 2:1.

[Øyvind]

Hello, our team ia looking into this and will need to do more testing on their side to confirm behavior. I have asked for a timeline and will get back to you as soon as I have more information.

Kind regards,
Øyvind

[Øyvind]

Hello, my sincere apologies for the late reply and any inconvenience this is causing. Our team are working on the matter and in contact with Arm Support. 

Kind regards,
Øyvind

[Øyvind]

Our team provided an answer back to me today and inform me that they have not been able to narrow down any problem in the Cortex M33 HW

Kind regards,
Øyvind