SLAU847D October 2022 – May 2024 MSPM0L1105 , MSPM0L1106 , MSPM0L1227 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1304-Q1 , MSPM0L1305 , MSPM0L1305-Q1 , MSPM0L1306 , MSPM0L1306-Q1 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2227 , MSPM0L2228 , MSPM0L2228-Q1
To support mapping of more than 32 peripheral interrupt sources to the NVIC, certain MSPM0 devices include interrupt grouping logic (INT_GROUP) in the MCPUSS to combine several interrupts together to source one native NVIC interrupt.
The INT_GROUP interrupt grouping uses the MSPM0 event management register structure with the key difference being that all peripheral interrupt sources to the interrupt group are always unmasked (always enabled) such that no additional enable configuration is needed beyond the peripheral interrupt configuration and the NVIC configuration. The IMASK register itself is read-only and hardwired to enable all sources to the interrupt group. Figure 3-4 shows the INT_GROUP structure.
Because no masking control is required, application software only needs to interface with the interrupt index (IIDX) register to efficiently handle a peripheral interrupt which is registered to the NVIC through an INT_GROUP.
Application software can read the IIDX register in the INT_GROUP to determine and clear the highest priority pending peripheral interrupt in the group. A read to IIDX will return an index corresponding to the highest priority peripheral which set an interrupt. The read action will also simultaneously clear the RIS and MIS bits corresponding to the highest priority interrupt whose index was returned by the read. The value read from the IIDX register can then be used in a case statement, as shown below.
void GROUP_HANDLER(void)
{
switch(IIDX)
{
case 0: // no IRQ pending
break;
case 1: // IRQ[0]
do_peripheral_1_ISR();
break;
case 2: // IRQ[1]
do_peripheral_2_ISR();
break;
default: // out of range
illegal();
}
}
Because peripheral interrupts that are grouped together into an INT_GROUP source a single NVIC interrupt, it is not possible to have one peripheral interrupt in a group preempt the execution of an active handler for the interrupt group. For example, take the scenario where the WWDT0 interrupt request line and the PMCU interrupt request line are connected to INT_GROUP0, and INT_GROUP0 sources NVIC peripheral interrupt 0. If the WWDT0 interrupt is asserted, INT_GROUP0 will assert an interrupt request to the NVIC. If no higher priority interrupt is active, the NVIC will vector the processor to the INT_GROUP0 handler. Application software can then read the INT_GROUP0 IIDX register to determine that it was the WWDT0 that triggered the INT_GROUP0 interrupt on the NVIC, and software can jump to the WWDT0 handler function.
If the PMCU asserts its interrupt line while the processor is still in handler mode servicing the WWDT0 function (which is really a part of the INT_GROUP0 handler), the PMCU interrupt can not preempt the WWDT0 handler. When the WWDT0 handler completes, The INT_GROUP0 handler will return. At that time, the processor will see that the INT_GROUP0 request was asserted again (this time, due to the PMCU), and it will tail-chain a second entry to the interrupt handler. This time, application software will read the IIDX and determine that the PMCU was the cause of the INT_GROUP0 interrupt being asserted to the NVIC.
If there are two or more peripheral interrupts pending to a single interrupt group, software can set the priority with which the interrupts are handled by first reading the RIS or MIS register to test which peripheral interrupts are asserted, followed by executing the software-determined priority. Alternatively, if the interrupt index (IIDX) register is used, the interrupt group hardware will return the highest priority index based on the index order.