This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1290NCPDT: assigning interrupt sub group priorties

Part Number: TM4C1290NCPDT

The application has several interrupts that happen in sequence within a very short time duration

(following PWM interrupt). I am trying to assign interrupt sub priorities that match the sequence

of events if there are multiple pending interrupts.. 

IntPriorityGroupingSet(NVIC_APINT_PRIGROUP_1_7);

Does this API mean all interrupts in this group have priority 1, with 7 possible sub priorities?

This is what will work with the application.

How to mark an interrupt as belonging to this group?

How to assign a sub priority to this set of interrupts?

Thanks,

Priya

  • If you want to change the default order in which pending interrupts are serviced, but not allow them to preempt an executing interrupt routine you can change the NVIC so that it has a single priority level with 8 possible sub-priorities. I admit that the use of the function is confusing, but call IntPriorityGroupingSet(0). The argument is the number of bits for the priority. It can be 0, 1, 2 or 3. Since you want all three bits for sub-priority, you have 0 bits for priority.

    Use the function IntPrioritySet() with sub-priorities of 0x00, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0 or 0xE0 (listed from most urgent to least urgent). Also remember that each interrupt source has its own innate priority based on its interrupt number. When in the same sub-priority, the interrupt with the lower interrupt number will be serviced first. You can see the interrupt numbers in hw_ints.h.

  • Bob

    Thank you for your reply. Does the group have a priority? If 8 sub priorities are used,

    is the default interrupt priority of this group 0?

    If I were to use one bit for the interrupt priority (priority = 1), then do I assign

    0x40, 0x50, 0x60, 0x70 to these 4 interrupts as defined sub priorities?

    For 4 sub priorities, do I define IntPriorityGroupingSet(2)? 

    If not, what else to set this to?

    Priya

  • Yes, all interrupts will be in priority group 0 if all 3 bits are used for 8 sub priorities. If you allocate one bit for group priority, then levels 0x00, 0x20, 0x40 and 0x60 are on group priority 0 (highest urgency) and levels, 0x80, 0xA0, 0xC0 and 0xE0 are on group priority 1 (less urgent). An interrupt on level 0x60 can pre-empt an interrupt routine from level 0x80 (different group levels), but level 0x80 cannot pre-empt level 0xA0 (same group level, different sub-prioity).

  • Bob,

    Can you explain setting sub priorities for a given group priority?

    For 4 sub priorities, do I set IntPriorityGroupingSet(2)? 

    Thank you again,

    Priya

     

  • There are three bits on the TM4C devices that can be used to set the priority. They are the three most significant bits of a byte so the valid priorities are:  0x00, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0 or 0xE0. The three most significant bits of each byte are 0, 1, 2, 3, 4, 5, 6 or 7. Now whether the bits determine the group priority or sub-priority is dependent on the call to  IntPriorityGroupingSet(). You pass the number of bits that you want to be used for the group priority. Since there are only three bits available, the valid options are 0, 1, 2 or 3. By default all three bits are used for group priority, there are no sub-priorities. Here is a table from page 171 of the datasheet that shows the tradeoff between group priorities and sub-priorities:

    Now back to your question. If you call  IntPriorityGroupingSet(2), you have allocated 2 bits to group priority. That leaves only 1 bit for sub-priorities. That means you will have 4 groups (2^2) each with 2 sub-priorities (2^1). If you want 4 sub-priorities, use  IntPriorityGroupingSet(1). That allocates one bit to the group priority (giving 2 groups) and 2 bits to the sub-priorities (four sub-priorities for each group).

  • Bob--

    Please review/correct the following:

    IntPriorityGroupingSet(0);

    IntPrioritySet(INT1, 0x00); 
    IntPrioritySet(INT2, 0x20); 
    IntPrioritySet(INT3, 0x40);    
    IntPrioritySet(INT4, 0x60);    

    Is this how I assign 4 interrupts to group priority 0? What connects these 4 interrupts to this group?

    Thanks,

    Priya

  • Greetings,

    Much patience & "insider tech insight" evident w/in this thread.    Applause to vendor's Bob for such an, "On-going & Multi-Layered" response.

    My small, young team offers up the following observations - intended to prove, "Less Wearing upon the (3x already responding) vendor agent:"

    • Poster "Experimentation" often can provide insights & clarity - even faster than awaiting the, "Poster-Vendor" response cycle
    • Not always will such keen "Vendor Assistance" arrive at one's doorstep.    (further support/drive towards 'Self-Help' via experimentation - when moving from student to employee - or advancing "On the Job" - and, "No such tech assistance is 'so readily' available.)

    W/in the opening post it was noted: "App has several interrupts that happen in sequence within a very short time duration."    On occasion - this, "too quick & grouped/massed arrival" of interrupts (may) reflect "Inadequate and/or (even) unsound program design."    Our group has found that "further program examination & analysis" may enable (both) the reduction of such interrupts & their (more relaxed - i.e. spaced) occurrence & arrival.      For example - our group has found that: several interrupts may be, "combined w/in just one" (and/or 'managed' via a single ISR) and/or the "known" (earliest arriving interrupt) may "Selectively Enable" specific "Follow-On" interrupts.    (Indeed each case is different - yet in general - such method has 'Saved Us' from such "Deep Dive into Interrupt Sub-Priorities!")

    Dictating a "Singular Solution" may not always prove optimal - being "open to other program means/methods" -  regularly enables/provides added insights & advantages...

  • The application uses 17 interrupts. The way I understand the priority grouping, I see it working only if the application uses 8 or 4 interrupts or fewer. 

    Thanks,

    Priya

  • If you call IntPriorityGroupingSet(0); you allocate 0 bits to the group and 3 bits to the sub-priority. That means all interrupts will be in group 0. Let's use the GPIO port interrupts as an example. From "inc\hw_ints.h" we can see the inherent priority of the GPIO port interrupts:

    #define INT_GPIOA_TM4C129       16          // GPIO Port A
    #define INT_GPIOB_TM4C129       17          // GPIO Port B
    #define INT_GPIOC_TM4C129       18          // GPIO Port C
    #define INT_GPIOD_TM4C129       19          // GPIO Port D
    #define INT_GPIOE_TM4C129       20          // GPIO Port E
    

    The lower the number, the more urgent the interrupt. Port A has the highest urgency. If we wanted to reverse the order such that if all four Ports A-D were pending and we wanted the port D interrupt to be serviced first, we would assign each to different sub-priorities:

      IntPrioritySet(INT_GPIOA, 0x60);
      IntPrioritySet(INT_GPIOB, 0x40);
      IntPrioritySet(INT_GPIOC, 0x20);  
      IntPrioritySet(INT_GPIOD, 0x00);    

    Now GPIOD is in sub-priority 0, and the most urgent of the four interrupts. By default, all interrupts start out as group 0. Therefore if GPIOE interrupt was pending as well as the other four, GPIOD would be serviced first because it is in group 0, sub-priority 0 and inherent number 19. The next would be GPIOE because it is in group 0, sub-priority 0 (by default) and inherent number 20 (20 > 19). Next would be GPIOC because it is in group 0, sub-priority 1 (0x20 >> 5) and inherent number 18. Next would be GPIOB because it is in group 0, sub-priority 2 (0x40 >> 5) and inherent number 17. Finally would be GPIOA because it is in group 0, sub-priority 3 (0x60 >> 5) and inherent number 16.

  • It is true that you do not have enough sub-priority bits to totally invert the order of the 129 interrupt sources on the TM4C129 device. But remember each interrupt source has an inherent priority. You can choose your hardware connections such that you make use of the inherent priority. For example, use GPIOA pins for interrupts that you want more urgent and GPIOB for less urgent. You can then have them in the same sub-priority and let the inherent interrupt number determine the final priority.

    Just a note. Interrupt routines should be short. Your interrupt response time should not be so critical for all of your interrupts so that you must dictate the priority of each source. If you must have a long interrupt routine and you have other very time critical interrupts, that long routine should be premptable.