TMS320F28235: C28x Interrupt Priorities

When an interrupt is taken, all other interrupts are disabled.  The software, however, can re-enable interrupts allowing others to interrupt the ISR that is running. We refer to it as interrupt nesting. 

This article explains in more detail: https://software-dl.ti.com/C2000/docs/c28x_interrupt_nesting/html/index.html

Hello Lori,

Thank you for the link to the article on interrupt nesting, which is helpful. 

As you say, when an interrupt is taken, the processor disables all other interrupts by setting INTM to 1, so my question should have been more precise.

I am interested in what happens if the interrupt handler enables interrupts by setting INTM to 0 - am I right in thinking that at this point, any interrupt that is not masked in IER (or PIEIERx.y) can occur, regardless of hardware prioritisation order?

More specifically, my question relates to the interrupt dispatching mechanism in SYS/BIOS, which enables auto-nesting support by default. The relevant code is lines 1145-1155 of Hwi_dispatchCore() in Hwi.c:

/* Propagate self bit which is auto cleared by hardware */
IER |= hwi->ierBitMask;

oldIER = IER;
IER &= ~hwi->disableMask;

__enable_interrupts();
(hwi->fxn)(hwi->arg);
__disable_interrupts();

IER |= (hwi->restoreMask & oldIER);
 

SYS/BIOS allows the interrupt masking behaviour to be configured with a MaskingOption, which can be set to various values including ALL, NONE, SELF. There is also a LOWER option that would disable all interrupts at the current and lower interrupt priority, but the documentation states that only a few targets/devices truly support this masking option.

Suppose an INT2 interrupt occurs and the masking option is set to SELF. Am I right in thinking that during the execution of the interrupt service routine, only INT2 interrupts are disabled and interrupts at other levels are enabled, regardless of whether they have a higher or lower hardware interrupt priority?

Thank you.

Robert Stroud

P.S. For the purposes of this question, I'm ignoring the PIE controller, which provides another layer of interrupt prioritisation and masking

Robert Stroud said:

I am interested in what happens if the interrupt handler enables interrupts by setting INTM to 0 - am I right in thinking that at this point, any interrupt that is not masked in IER (or PIEIERx.y) can occur, regardless of hardware prioritisation order?

Yes, but the HW prioritization will take place again. That is the PIE / CPU will take the highest interrupt both enabled and flagged. Also note that when the ISR was entered the IER bit was cleared as well as INTM.

Robert Stroud said:

Suppose an INT2 interrupt occurs and the masking option is set to SELF. Am I right in thinking that during the execution of the interrupt service routine, only INT2 interrupts are disabled and interrupts at other levels are enabled, regardless of whether they have a higher or lower hardware interrupt priority?

I'll see if someone more familiar with DSP/BIOS can respond.

In the example, if you take INT2, then in the ISR INTM will be set and IER.2 will be cleared. This disables all interrupts (INTM = 1) and all INT2 interrupts (IER.2 = 0).  If the SW then clears the global mask (INTM=0) then all interrupts that were enabled before ISR2 are re-enabled EXCEPT ISR2. (because IER.2 was cleared by the hardware).  

I found a getting started slide set that describes the following - 

SELF - all other HWI can pre-empt except for itself. I suspect this just makes sure the IER bit (IER.2 in the example) is clear. This is the state when an interrupt is entered by default.

ALL - best choice if ISR is short and fast. So this must mask all the ISRs - this could be done by clearing IER bits or by setting the INTM. It is also the default state (INTM = 1) when an interrupt is entered. 

BITMASK - allows a custom mask. This must let you set a custom mask for IER and disable specific interrupts. 

From the code you posted I'm assuming nothing is done at the PIEIERx level by these settings - that may or may not be a good assumption.

Robert - I do want to make sure you know that SYS/BIOS is no longer updated or maintained. All of the TI processors are now supporting Free RTOS. C2000Ware has support for the C28x. 

Lori, thank you for following up on my question. Yes, I'm aware that SYS/BIOS is no longer updated or maintained, but I'm analysing the behaviour of some 3rd-party code that was written using SYS/BIOS.

Despite this, my question isn't really about SYS/BIOS, it's about whether the C28x processor has any notion of interrupt priority level. On some processors, if an INT4 occurs, the processor automatically blocks any interrupts whose priority is 4 or less. This means that if there are N interrupt levels, you can have at most N interrupts in increasing interrupt priority level before the processor interrupt level is set to the highest value and further interrupts are blocked.

As far as I can tell, the C28x doesn't behave like this, although you could simulate this behaviour by clearing the appropriate bits in the IER.

This means that once an interrupt handler is running, the hardware interrupt priority level is irrelevant - it is only used to prioritise simultaneous interrupts and choose the interrupt vector with the highest priority. Once an interrupt has been dispatched, the interrupt handler can be interrupted by a nested interrupt with a higher or lower hardware interrupt priority, assuming the nested interrupt is enabled in the IER.

In principle, since the hardware clears the corresponding bit in the IER when an interrupt occurs, you can have at most N nested interrupts in any order before all interrupts are disabled in the IER - in this case, N=14 if you ignore the hardware debugging interrupts. 

However, if the interrupt dispatcher re-enables the self-bit in the IER, which is what the default interrupt dispatcher SYS/BIOS does (see above), in principle, you could have an indefinite sequence of nested interrupts in any hardware priority order.

Is my understanding correct?

Thanks,

Robert

If INT4 occurs, all other interrupts are blocked by INTM and IER.4 is cleared.

It is up to the SW to clear INTM and update IER if required (as you say to simulate blocking all lower priority interrupts) to re-enable any interrupts.

Robert Stroud said:

Once an interrupt has been dispatched, the interrupt handler can be interrupted by a nested interrupt with a higher or lower hardware interrupt priority, assuming the nested interrupt is enabled in the IER.

Correct. The only HW prioritization would be the highest interrupt both flagged and enabled will be taken first.

"INT4 is running" wouldn't be part of the prioritization by the HW.  "INT4 is running" would have to be taken into account by the SW setting/clearing appropriate IER bits.