1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

LPC2103 reset when disabling interrupt in VIC

Discussion in 'Embedded' started by Jon, Apr 15, 2008.

  1. Jon

    Jon Guest


    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, Apr 15, 2008
    1. Advertisements

  2. Jon

    Arlet Ottens Guest

    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.
    Arlet Ottens, Apr 15, 2008
    1. Advertisements

  3. Jon

    Rich Webb Guest

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

    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, Apr 15, 2008
  4. 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.
    Mike Harrison, Apr 15, 2008
  5. Jon

    Jon Guest

    You guys are wonderful :) It was a spurious interrupt. Problem
    Thanks again.
    Jon, Apr 16, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.