Forums

LPC2103 reset when disabling interrupt in VIC

Started by Jon April 15, 2008
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<<VIC_TIMER0;
the micro gets reset. Quite mysterious. Does anyone have a hint on why
this could be happening?
If the VIC is able to generate a reset (directly or indirectly), is
there any interrupt vector where I can place a breakpoint, to stop the
execution right before the reset occurs, and to confirm that it is
indeed the VIC who is complaining about something?

Thank you very much,
Jon

Jon wrote:

> 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<<VIC_TIMER0; > the micro gets reset. Quite mysterious. Does anyone have a hint on why > this could be happening? > If the VIC is able to generate a reset (directly or indirectly), is > there any interrupt vector where I can place a breakpoint, to stop the > execution right before the reset occurs, and to confirm that it is > indeed the VIC who is complaining about something?
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.
On Tue, 15 Apr 2008 14:47:35 +0200, Jon <a@b.c> wrote:

>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<<VIC_TIMER0; >the micro gets reset. Quite mysterious. Does anyone have a hint on why >this could be happening? >If the VIC is able to generate a reset (directly or indirectly), is >there any interrupt vector where I can place a breakpoint, to stop the >execution right before the reset occurs, and to confirm that it is >indeed the VIC who is complaining about something?
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
On Tue, 15 Apr 2008 14:47:35 +0200, Jon <a@b.c> wrote:

>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<<VIC_TIMER0; >the micro gets reset. Quite mysterious. Does anyone have a hint on why >this could be happening? >If the VIC is able to generate a reset (directly or indirectly), is >there any interrupt vector where I can place a breakpoint, to stop the >execution right before the reset occurs, and to confirm that it is >indeed the VIC who is complaining about something? > >Thank you very much, >Jon
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.
You guys are wonderful :-) It was a spurious interrupt. Problem
solved.
Thanks again.