How can this wild interrupt occur?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi:

I am trying to selectively disable an interrupt during a sequence of
code where I don't want that interrupt to occur, on a TMS320F2812 DSP.
The interrupt is CPU Timer0, and the code of interest is within another
interrupt, EVB Timer4's compare match interrupt.  This T4CINT ISR must
be preemptable by EVA Timer2 interrupts, so I cannot globally disable
interrupts here.  Just need to block CPU Timer0.

There are two methods which work to disable the interrupt temporarily
then reenable it after the critical code (note the example codes utilize
symbols from "C_C++ Peripheral Headers" sprc097.zip):

METHOD 1:
-------------------------
/* Disable INT1 in the CPU IER, then reenable it after critical code */

IER &= ~M_INT1;  /* Since the PIE passes Timer0 int to CPU INT1 */
asm(" nop");  /* takes about 3 cycles to ensure a pending interrupt */
asm(" nop");  /* prior to disabling is serviced before entering */
asm(" nop");  /* critical code */
        
{  critical code  }

IER |= M_INT1;  /* Any pending Timer0 int will now exec */
-------------------------


METHOD 2:
-------------------------
/* Disable TIE in the CPU Timer0 control registers, then reanable after
critical code */

CpuTimer0Regs.TCR.bit.TIE = 0;
asm(" nop");
asm(" nop");
asm(" nop");

{  critical code  }

CpuTimer0Regs.TCR.bit.TIE = 1;
-------------------------


This next way causes PDPINTA on PIE1.1 to accidentally execute:

METHOD 3:
-------------------------
/* Disable Timer0 int in the PIEIER, then reanable after critical code */

PieCtrlRegs.PIEIER1.bit.INTx7 = 0;
asm(" nop");
asm(" nop");
asm(" nop");

{  critical code  }

PieCtrlRegs.PIEIER1.bit.INTx7 = 1;
-------------------------

In this 3rd method, what appears to happen is that the Timer0 flag
propagates through to the CPU core IFR at the same time or just prior to
unsetting the PIEIER1.7 enable bit.  Thus, the CPU vectors, but since
the PIEIER1 register has no set bit, it doesn't know which vector.  It
chooses INT1.1 by default which is the PDPINTA.

I'm not sure if this could be considered a CPU bug or not, but it is a
potentially serious gotcha that one should be aware of when using this CPU.


Anyone else noticed this?



--
Good day!

________________________________________
We've slightly trimmed the long signature. Click to see the full one.
Re: How can this wild interrupt occur?
Quoted text here. Click to load it


Actually, this behavior is accounted for in the "System Control and
Interrupts" user guide.

Jeez, it sure takes a long time to absorb the mass of documentation for
even a small portion of this beast.

And it's TIs

Good day!


--
_____________________
Christopher R. Carlen
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline