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!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen
Loading thread data ...

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
 Click to see the full signature
Reply to
CC

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.