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.

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

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.

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