Sorting out interrupts on LPC2103 still..

Comments

3 comments

  • Avatar
    Jon Elliott

    This indicates your program is jumping to 0x00000000 some time after you enable interrupts.

    Without the complete project it is impossible to tell what you've done for certain but I would guess the problem is that you've set up the interrupt to vector directly to external_interrupt_2 and it is jumping to 0x00000000 on exit because external_interrupt_2 does not have the appropriate IRQ handler exit code. The examples we ship don't define VECTORED_IRQ_INTERRUPTS, they instead let the CTL irq_handler function sort out the vectoring - this simplifies matters greatly and allows you to write your ISR as a regular C function.

    The alternative is to use the __attribute__ ((interrupt("IRQ"))) syntax to mark the external_interrupt_2 function as an IRQ handler - I would advise against this however as we've seen a lot of problems in the past when compiling IRQ functions with optimization enabled.

    Regarding the FIQ handler, if you're using our startup code you'll need to implement a FIQ handler called fiq_handler, enable FIQ interrupts (which you can do by calling the libarm_enable_fiq() function) and of course setup the interrupt controller to generate the appropriate FIQ interrupt. If your handler uses any stack you'll also need to set the Stack Size (FIQ Mode) property to the appropriate value. The warning regarding using  __attribute__ ((interrupt("IRQ"))) also applies to using  __attribute__ ((interrupt("FIQ"))) - if you're going to write a fiq_handler I'd write at least the entry and exit code yourself in assembly code.

    Regards,

    Jon Elliott

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    Paul,

    I've just had your email passed to me (BTW, you can attach files to your forum entries or if you want privacy you could create a ticket).

    > I am running the attached project using an Olimex USB Tiny.  I can connect and debug.
    > The thing runs but immediately jumps into the interrupt and keeps looping through there without ever getting out into main().

    Presumably the interrupt keeps triggering because the cause of the interrupt isn't being cleared.

    What do you have connected to EXT2? Looking at your program you've not set up the EXTMODE or EXTPOLAR so by default the EXT2 interrupt will be low level triggered - therefore if EXT2 is low, the interrupt will keep triggering.

    Regards,

    Jon Elliott

    0
    Comment actions Permalink
  • Avatar
    Paul Robert Gaastra

    Thanks Jon

    Phew, that's it!  You hit the nail on the head.  It was the EXTMODE and EXTPOLAR.  I had just put together the bare bones program not transfering the EXTMODE setting from my original program.  I had EXT2 connected to ground thinking I wasn't causing an interrupt.  Somehow I missed EXTPOLAR in my original program and it worked (probably by good luck rather than good management).   I was sure I had a preprocessor setting wrong or something. 

    P.S.  I see there is a place to vote for "Make CrossWorks manual available as a PDF document "  I would heartily endorse that.  To me, clicking on links in web pages is sort of like being in a straight jacket compared to having a printed manual.  Maybe if there was a google search engine on the online documentation? I see there is a manual at  http://www.rowley.co.uk/arm/arm_manual.pdf  but I don't know whether it is the latest.  I can't see anyway from any Rowley site to navigate to it either.

     

    0
    Comment actions Permalink

Please sign in to leave a comment.