Is it possible to set NVIC priority group of nRF9160?

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

Parents
  • 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

  • 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

  • Hello  and  
    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

  • Hello,

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

    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.

  • 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

  • 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

Reply Children
Related