Kelvin, For having nested interrupts, the processor needs to be put in any other mode other than IRQ before enabling the interrups. Otherwise the IRQ_LR would get corrupted (System mode was invented for this purpose, I guess). There are several ways to exit from IRQ mode, but should be returned to the address IRQ_LR - #4 Cheers, -Mike. --- Robert Adsett <> wrote: > At 10:40 AM 10/9/04 -0700, you wrote: > >This may be, perhaps, a bit off topic. > > I'd call it on topic. > >I'm trying to make sense of the IRQ modle of the > ARM core on the lpc2124. My > >understanding of how this works is based on the ARM > port to Linux, and the > >ARM refrence manual. > > > >I'm a bit confused. > > > >On IRQ interrupt (not FIQ) the CPU switches to the > ARM interrupt registers > >and > >branches to the irq vector currently installed. > > It does do a similar thing for the FIQ, just a > different set of registers. > >The ARM manual states that your ISR should do its > thing, and to return > >back to > >the interrupted state execute "subs pc lr 4" or > something very close (I'm > >doing this from memory at the moment so the actual > instruction may be a bit > >different). > > So far so good. > >However; in Linux this happens the following way; > >entry.S has the __irq_svr handler, that calls > do_IRQ, now do_IRQ sometime > >can / will re-enable interrupts. > > > >Now how can another IRQ happen before returning > back to the non-IRQ > >register? > >Wouldn't that mess things up if it one did? > > Not if done correctly. Several things have to > happen to make this work. > > - first the PSR of the interrupted process must be > saved so that it can be > restored when the interrupt is finally exited > - The return address has to be calculated and saved > somewhere so it won't > be corrupted and can be used to exit the interrupt > - Any necessary registers should be saved. > > At this point interrupts can be reenabled. > Sometimes the code will change > processor modes to facilitate this. > > Exiting from interrupts essentially reverses this > process. > > - The saved PSR is restored to the SPSR register > - and the calculated return address is restored to > R14 > - and finally the interrupt can be exited using an > instruction like > > movs pc, r14 > > which tells the micro to return while changing modes > and restoring the PSR > using the SPSR register. > > The "ARM Architecture Reference Manual" ARM ARM ? > ;) is quite usefule for > going through the details. > > Don't use the above as more than a rough guide, > definitely check out the > details, but that should give you the general idea > of how it works. > > >My other problem is that I cannot find that magic > opcode ("subs pc lr 4") to > >return from the interrupt, is there another way to > return the ARM processor > >registers to non-IRQ register set? Or is this just > an Linux-ism. > > Not a linux-ism, there are several ways to return > from an interrupt. > > Robert > > " 'Freedom' has no meaning of itself. There are > always restrictions, > be they legal, genetic, or physical. If you don't > believe me, try to > chew a radio signal. " > > Kelvin Throop, III _______________________________

An Engineer's Guide to the LPC2100 Series

At 10:40 AM 10/9/04 -0700, you wrote: >This may be, perhaps, a bit off topic. I'd call it on topic. >I'm trying to make sense of the IRQ modle of the ARM core on the lpc2124. My >understanding of how this works is based on the ARM port to Linux, and the >ARM refrence manual. > >I'm a bit confused. > >On IRQ interrupt (not FIQ) the CPU switches to the ARM interrupt registers >and >branches to the irq vector currently installed. It does do a similar thing for the FIQ, just a different set of registers. >The ARM manual states that your ISR should do its thing, and to return >back to >the interrupted state execute "subs pc lr 4" or something very close (I'm >doing this from memory at the moment so the actual instruction may be a bit >different). So far so good. >However; in Linux this happens the following way; >entry.S has the __irq_svr handler, that calls do_IRQ, now do_IRQ sometime >can / will re-enable interrupts. > >Now how can another IRQ happen before returning back to the non-IRQ >register? >Wouldn't that mess things up if it one did? Not if done correctly. Several things have to happen to make this work. - first the PSR of the interrupted process must be saved so that it can be restored when the interrupt is finally exited - The return address has to be calculated and saved somewhere so it won't be corrupted and can be used to exit the interrupt - Any necessary registers should be saved. At this point interrupts can be reenabled. Sometimes the code will change processor modes to facilitate this. Exiting from interrupts essentially reverses this process. - The saved PSR is restored to the SPSR register - and the calculated return address is restored to R14 - and finally the interrupt can be exited using an instruction like movs pc, r14 which tells the micro to return while changing modes and restoring the PSR using the SPSR register. The "ARM Architecture Reference Manual" ARM ARM ? ;) is quite usefule for going through the details. Don't use the above as more than a rough guide, definitely check out the details, but that should give you the general idea of how it works. >My other problem is that I cannot find that magic opcode ("subs pc lr 4") to >return from the interrupt, is there another way to return the ARM processor >registers to non-IRQ register set? Or is this just an Linux-ism. Not a linux-ism, there are several ways to return from an interrupt. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III

This may be, perhaps, a bit off topic. I'm trying to make sense of the IRQ modle of the ARM core on the lpc2124. My understanding of how this works is based on the ARM port to Linux, and the ARM refrence manual. I'm a bit confused. On IRQ interrupt (not FIQ) the CPU switches to the ARM interrupt registers and branches to the irq vector currently installed. The ARM manual states that your ISR should do its thing, and to return back to the interrupted state execute "subs pc lr 4" or something very close (I'm doing this from memory at the moment so the actual instruction may be a bit different). However; in Linux this happens the following way; entry.S has the __irq_svr handler, that calls do_IRQ, now do_IRQ sometime can / will re-enable interrupts. Now how can another IRQ happen before returning back to the non-IRQ register? Wouldn't that mess things up if it one did? My other problem is that I cannot find that magic opcode ("subs pc lr 4") to return from the interrupt, is there another way to return the ARM processor registers to non-IRQ register set? Or is this just an Linux-ism. Sorry once again that this a bit off topic. (It is an ARM question... ;) Thanks, --mgross