How can this wild interrupt occur?

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!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

Chris Carlen wrote:
> Hi:[edit]
> 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?


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
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5