LPC2103 reset when disabling interrupt in VIC

Hi,

I'm using:

- NXP LPC2103FBD48 with ARM7 core.

- Rowley Associates CrossStudio for ARM v1.7 build 4.

Sometimes, when I disable the interrupt corresponding to TIMER0, doing VICIntEnClr =1

Reply to
Jon
Loading thread data ...

Could it be that you disable this interrupt (IRQ ?) just when the TIMER0 peripheral is asserting it, while the CPU has interrupts still enabled ?

If so, this could be a problem. The ARM core doesn't like glitches on the IRQ signal. I've seen it take the FIQ vector as a result.

If this is happening, try disabling the CPU interrupt first.

You must also guarantee that the write has actually modified the register before enabling the CPU interrupts again. On some platforms, an easy way to do that is to write the register twice, or to read it back.

Reply to
Arlet Ottens

See NXP app note AN10414 "Handling of spurious interrupts in the LPC2000."

From the Introduction to the above: "Spurious interrupts can occur in the LPC2000 just like in any ARM7TDMI-S based microcontroller using the Vectored Interrupt Controller (VIC) and if handled correctly, spurious interrupts can be serviced just like any other interrupt request. As shown in the test cases below, they cause the interrupt to be serviced in a different handler as compared to the original interrupt handler itself. If not handled correctly, the application might experience a reset-like behavior."

Short version, as I understand it: There's a default vector in the VIC for un-handled interrupts which defaults to 0x00000000, e.g., it looks like a reset event.

Disabling the timer0 interrupt sounds like just the kind of race condition that could produce an unhandled event. In your case, you could have a stub handler that just does a normal return from interrupt and point the default vector there.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

The VIC is probably directing the int to the undefined int vector, which defaults to 0, i.e. reset. You need to disable the int in the timer interrupt regs.

Reply to
Mike Harrison

You guys are wonderful :-) It was a spurious interrupt. Problem solved. Thanks again.

Reply to
Jon

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.