RE: TM4C1290NCPDT: assigning interrupt sub group priorties

Bob Crosby said:

The second statement is not talking about group numbers, rather the value passed to the function IntPriorityGroupinSet().

So the datasheet table group numbers 0x0 - 0x4 don't match the Tivaware function call as to confuse everyone? That older grouping order may be left over from Stellarisware migration since those groups don't match the newer TM4C table.  

Bob Crosby said:

greater than three still only gives you three bits for determining the preemptable groups.

Yet when I tried to set IntPriorityGroupingSet(2) for the same 8 sub priority groups with 23 interrupts it caused odd failures. However IntPriorityGorupingSet(4) works without any issues for several interrupts inside sub priority groups 0x0, 0x20, 0x40, 0x60, 0x80, 0xE0. If group 0-2 had the same effect noting would cause interrupt issues but it does. 

Bob Crosby said:

three bits are available for hardware interrupt prioritization and therefore priority grouping values of three through seven have the same effect

Why does 3-7 exist in the table if those groups can not be split into sub priorities and confuse us the entire table is valid when Tivaware function note claims otherwise. Oddly grouping 4 works and grouping 2 seems like it don't work at all. Also Tivaware example applications have priority grouping 4 configured, why not 0 or 2.

Oddly interrupt.c  PRIGROUP_4_4 is 0x300 selects 3 bits for the group priority field (bxxx.) Table 3-9 field bits (0x0 - 0x4) = 8 priority groups 1 sub priority. Perhaps why IntPrioritryGroupingSet(2) selects 0x500 (bxx.y) PRIGROUP 2_6 or 4 groups with 2 sub priorities. It seems the constant names are not exactly split as table 3-9 shows and expected for the TM4C.

//*****************************************************************************
//
// This is a mapping between priority grouping encodings and the number of
// preemption priority bits.
//
//*****************************************************************************
static const uint32_t g_pui32Priority[] =
{
    NVIC_APINT_PRIGROUP_0_8, NVIC_APINT_PRIGROUP_1_7, NVIC_APINT_PRIGROUP_2_6,
    NVIC_APINT_PRIGROUP_3_5, NVIC_APINT_PRIGROUP_4_4, NVIC_APINT_PRIGROUP_5_3,
    NVIC_APINT_PRIGROUP_6_2, NVIC_APINT_PRIGROUP_7_1
};

Bob Crosby said:

IntPriorityGroupingSet(4) will allocate all 3 bits to preemptable groups. It is exactly the same as IntPriorityGroupingSet(3). Here is the table in another form to help make it more clear:

So datasheet table 3-9 is not telling the truth of how priority groups and sub priority must exist in row 1 last 2 columns.

I read table 3-9 row 1 as 0x0 - 0x4 all produce 8 group priorities 1 sub priority in each group. So 0x0-0x4 results in the same grouping according row 1 last 2 columns. It would be improper to make a table outcome of only one selections, 0x0 - 0x4. Doing such would invalidate all the other configurations and make the table less than informational, more confusing to the reader. 

However priority group field 1st column (0x5, 0x6, 0x7) will result in the specific grouping, sub order shown in the last 2 columns. Tivaware sets the PRIGROUP bit field [10:8] APINT register as show below table 3-9, relative to 1st column. Table 3-9 is talking about APINT bits [10:8] not Tivaware contsants used to configure APINT register bits. The constants for APINT have 0x000 - 0x004, 0x500, 0x600, 0x700 in the same [10:8] bits shown in table 3-9.  

Bob Crosby said:

IntPriorityGroupingSet(2)  two bits for premeptable groups, four preemptable groups each having two sub-priority groups

That sort of blows a hole in table 3-9 lay out and most will easily forget that several months from now.

Bob Crosby said:

The confusion comes because the table is created for the maximum possible bits, 8, but the TM4C only implements 3. 

So table 3-9 is not for TM4C1294 MCU and some other MCU?

Has table 3-9 been corrected in a later datasheet versions as readers with short term memory loss may forget this thread ever existed 6 months from now?

Forgot new Acrobat reader has built add of sticky notes into unlocked PDF. So added above new table 3-9 group definitions to the datasheet as a bug note.

Bob Crosby said:

Table 3-9 is correct, but column one is the bitfield of the APINT register, not the parameter that is passed to the IntPriorityGroupingSet() function.

Check again as it shows below address offset and is the hex/binary code for bits [10:8]

Application Interrupt and Reset Control (APINT)

Base 0xE000.E000
Offset 0xD0C
Type RW, reset 0xFA05.0000

There is always the distinct possibility table 3-9 is correct and the NVIC is acting more like you have outlined in your above table listing. Perhaps edit 0x0 above to indicate 1 sub priority. Interrupt/s having the lowest number with in the sub priority in each group have priority over higher number interrupts. That is how 23 interrupts can allow NVIC tail chaining to work so well, keeping that in mind.

Bob Crosby said:

Coming out of reset you have 8 groups each with a single sub-priority group.

Decided to test grouping 0x0 after you mention above for the same 23 interrupts 8 groups. What happened next was odd sequential phasing between all the interrupts occurred. It seems 0x3-0x4 are 8 groups 1 sub priority being the interrupt number value within each group.