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

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