Hi,

Im an undergrad student, with an experience of the past 15 days on the
AT91RM9200, the first uC ive worked with, besides the one week spent on
an 89c51, so im a real greenhorn to embedded systems. I am confused
about why we need to change the mode or the ARM core from irq to
sys..the atmel notes mention that the link register and the spsr would
be overwritten if another interrupt occurs..in that case, why can we
not just push the values of the above registers the stack, and stay in
the same mode?

also, when an interrupt occurs, the value stored in the register r14 is
PC +4..whys the 4 added??

thanx in anticipation

Mayank

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 08:02:07 -0800

Bill Pringlemeir wrote:

> > also, when an interrupt occurs, the value stored in the register
r14
> > is PC +4..whys the 4 added??
>
> The interrupt occurs after the instruction completes (in most cases).
> If it was not incremented, then you would run the same instruction
> twice. This is really bad if the instruction was a system call; you
> would have a recursive loop.

Bill, iv studied the 8085 processor last semester; there, the PC is
incremented as soon as the opcode fetch happens..here,do u agree that
theres a possibility that the PC had already been incremented, but a +4
value was still stored in the link regester..and, most confusingly, i
got this from the atmel "interrupt prioritization and handling" app
note:

;- IRQ Entry
;-----------
MACRO
IRQ_ENTRY $reg

;- Adjust and save LR_irq in IRQ stack
>>> sub r14, r14, #4
stmfd sp!, {r14}

if we were going to decrement this, why did we increment it in the
first place :-(

thanx in anticipation

Mayank

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 07:43:55 -0800

oops, sorry! Bill has already replied to this...that it would take lots
of time to store the regs/..additionally in the other mode we have lots
of new instructions available..
soreeee! :-)

From:	Tauno Voipio
Subject:	Re: Doubt about interrupt handling in AT91
Date:	Mon, 10 Jan 2005 20:05:44 GMT

Mayank Kaushik wrote:
> Hi,

Maybe I should not do your homework, but ...

> Im an undergrad student, with an experience of the past 15 days on the
> AT91RM9200, the first uC ive worked with, besides the one week spent on
> an 89c51, so im a real greenhorn to embedded systems. I am confused
> about why we need to change the mode or the ARM core from irq to
> sys..the atmel notes mention that the link register and the spsr would
> be overwritten if another interrupt occurs..in that case, why can we
> not just push the values of the above registers the stack, and stay in
> the same mode?

Yes, you can, but you cannot then enable interrupts for
nested interrupt handling. The link register is also used
for subroutine return linkage, so it cannot receive surprises
from interrupts.

You do have the option of not enabling other interrupts
for the duration of one handler. You have, however, to keep the
handler very quick, in order not to create too long
latencies for the other interrupts.

Please note that you need a separate stack for the interrupt
level - the stack pointer register is also changed during
the mode change at interrupt entry. The IRQ level stack
pointer has to be initialized during system intialization.

If you want to run the interrupt handler body in C,
your assembly language layer (called shim by ARM) has
to return to the user mode register set, but with
system privileges, thus the system mode. If you do this,
you can structure the code to work without an IRQ level
stack.

The IRQ mode needs to be restored on return from the
handler to provide proper state restoration at the
end of interrupt.

> also, when an interrupt occurs, the value stored in the register r14 is
> PC +4..whys the 4 added??

The core has already advanced the program counter to point to
the next instruction and it is cheaper to make the correction
in the interrupt handler software than on silicon. Besides,
the correction can be often combined with other operations,
e.g. the quick dismissal

subs pc,#4

which combines the state restoration and the pc pull-back.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

From:	Bill Pringlemeir
Subject:	Re: Doubt about interrupt handling in AT91
Date:	10 Jan 2005 15:14:48 -0500

> Mayank Kaushik wrote:

>> Im an undergrad student, with an experience of the past 15 days on
>> the AT91RM9200, the first uC ive worked with, besides the one week
>> spent on an 89c51, so im a real greenhorn to embedded systems. I am
>> confused about why we need to change the mode or the ARM core from
>> irq to sys..the atmel notes mention that the link register and the
>> spsr would be overwritten if another interrupt occurs..in that
>> case, why can we not just push the values of the above registers
>> the stack, and stay in the same mode?

On 10 Jan 2005, tauno.voipio@iki.INVALID.fi wrote:

> Maybe I should not do your homework, but ...

I'll help and give confusing information. ;-)

> Yes, you can, but you cannot then enable interrupts for
> nested interrupt handling. The link register is also used
> for subroutine return linkage, so it cannot receive surprises
> from interrupts.

> The IRQ mode needs to be restored on return from the
> handler to provide proper state restoration at the
> end of interrupt.

I guess this is a difference between x86, 68k and ARM/PPC, etc. The
link register is "volatile". You could push the link, the status and
the PC on the stack. I don't see how this would stop you from nesting
interrupts, etc. It points out that having the shadowed registers is
nice from a latency point of view.

>> also, when an interrupt occurs, the value stored in the register
>> r14 is PC +4..whys the 4 added??
>
> The core has already advanced the program counter to point to
> the next instruction and it is cheaper to make the correction
> in the interrupt handler software than on silicon. Besides,
> the correction can be often combined with other operations,
> e.g. the quick dismissal
>
> subs pc,#4
>
> which combines the state restoration and the pc pull-back.

I guess he has to combine our answers. The CPU is usually two
instructions ahead; pc + 8... at least with the original ARM and the
rest emulate it.

fwiw,
Bill Pringlemeir.

--
Sex is one of the nine reasons for reincarnation. The other eight are
unimportant. - unknown

From:	Wilco Dijkstra
Subject:	Re: Doubt about interrupt handling in AT91
Date:	Tue, 11 Jan 2005 10:40:31 GMT

"Bill Pringlemeir" wrote in message
news:m27jml59dz.fsf@sympatico.ca...
>
> > Mayank Kaushik wrote:

> > The IRQ mode needs to be restored on return from the
> > handler to provide proper state restoration at the
> > end of interrupt.
>
> I guess this is a difference between x86, 68k and ARM/PPC, etc. The
> link register is "volatile". You could push the link, the status and
> the PC on the stack. I don't see how this would stop you from nesting
> interrupts, etc. It points out that having the shadowed registers is
> nice from a latency point of view.

Just pushing the link and status register doesn't work, as this
means you can't use the link register at all in an interrupt routine.
If you do a BL and an interrupt is taken immediately afterwards
you never return from the BL. Also many compilers use LR as
a general purpose register and you can't tell them to stop using
LR. So you have to push LR *and* switch to a different mode if
you want nested interrupts.

Wilco

From:	Bill Pringlemeir
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 09:46:05 -0500

"Bill Pringlemeir" wrote in message

>> I guess this is a difference between x86, 68k and ARM/PPC, etc.
>> The link register is "volatile". You could push the link, the
>> status and the PC on the stack. I don't see how this would stop
>> you from nesting interrupts, etc. It points out that having the
>> shadowed registers is nice from a latency point of view.

On 11 Jan 2005, wilco-dot-dijkstra@ntlworld.com wrote:

> Just pushing the link and status register doesn't work, as this
> means you can't use the link register at all in an interrupt
> routine. If you do a BL and an interrupt is taken immediately
> afterwards you never return from the BL. Also many compilers use LR
> as a general purpose register and you can't tell them to stop using
> LR. So you have to push LR *and* switch to a different mode if you
> want nested interrupts.

The interrupt address would have to be pushed on the [interrupt] stack
and not placed in LR. I was assuming this. The LR would then have
the 'main lines' value, whether it was a return address or a general
purpose value. This is the way that other architectures do it.

fwiw,
Bill Pringlemeir.

--
Keep things as simple as possible, but no simpler. - A. Einstein

From:	Wilco Dijkstra
Subject:	Re: Doubt about interrupt handling in AT91
Date:	Tue, 11 Jan 2005 21:10:30 GMT

"Bill Pringlemeir" wrote in message
news:m2brbwdnwy.fsf@sympatico.ca...
> On 11 Jan 2005, wilco-dot-dijkstra@ntlworld.com wrote:
>
> > Just pushing the link and status register doesn't work, as this
> > means you can't use the link register at all in an interrupt
> > routine. If you do a BL and an interrupt is taken immediately
> > afterwards you never return from the BL. Also many compilers use LR
> > as a general purpose register and you can't tell them to stop using
> > LR. So you have to push LR *and* switch to a different mode if you
> > want nested interrupts.
>
> The interrupt address would have to be pushed on the [interrupt] stack
> and not placed in LR. I was assuming this. The LR would then have
> the 'main lines' value, whether it was a return address or a general
> purpose value. This is the way that other architectures do it.

OK, so you're talking about the other interrupt model - which isn't
used by current ARMs. Yes, if the hardware automatically saves
enough registers it can directly jump to an interrupt handler written
in C, and you never have to worry about modes or nested interrupts.
Cortex M3 does this. Although saving the registers takes some time,
this gives a better interrupt latency if you require nested interrupts
or C interrupt handlers (in which case you'll need to save the registers
anyway, so doing it in hardware while branching to the interrupt
handler is faster). However banked registers are better if you mainly
need non-nested interrupts.

Wilco

From:	William Munns
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 11:55:27 GMT

Bill Pringlemeir wrote in
news:m27jml59dz.fsf@sympatico.ca:

> The
> link register is "volatile". You could push the link, the
> status and the PC on the stack.

Nope, the link register is deterministic as far as the program
flow is concerned, thats why you have to push and pop the
register when you may corrupt it (eg. BL).
Getting an interrupt only corrupts the IRQ mode link register,
so it does not upset normal program flow unless that flow was
itself executing in IRQ mode.

>You could put the values on the stack. However, this would
>consume several bus cycles to transfer to memory

If you are using nested interrupts (the only* reason why you
would do this) then you have to push the LR and PSR from the
mode you are swithing to to the stack.

Will
*Alright in a twisted other universe you might decide not to
have FIQ's and handle all IRQ's by first switching into FIQ
mode, this would have the effect of saving the LR, but this
would be such a tiny saving as to not make it worth doing.

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 09:18:57 -0800

also, since interrupts are disabled once an exception occurs, theres no
danger of a new interrupt coming along and spoiling the party before
the LR etc are saved..infact, in the atmel app note, interrupts are
enabled only when going into the sys mode from the irq mode..
help:-((

From:	William Munns
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 17:27:03 GMT

"Mayank Kaushik" wrote in
news:1105463937.594457.9470@f14g2000cwb.googlegroups.com:

> also, since interrupts are disabled once an exception
> occurs, theres no danger of a new interrupt coming along
> and spoiling the party before the LR etc are saved.

Correct, but as soon as you BL the LR stops being 'saved' as it
is now 'in use'

> infact,
> in the atmel app note, interrupts are enabled only when
> going into the sys mode from the irq mode..

this is by choice, the mode switch and the IRQ enable happen at
the same time. But there is no point in the mode switch unless
you are re-enabling IRQ's

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 08:17:12 -0800

ah, i also got this from the arm architecture manual:
----
When an IRQ is detected, the following actions are performed:
R14_irq = address of next instruction to be executed + 4
----
also, since PC contains the address of the current instruction + 4, i
think the nut is trying to say that PC goes into R14_irq...if we reduce
this by 4, voila, we get to the next instruction in sequence...it fits!
but what happens to the other instructions in the pipeline...if i
remember correctly, they are discarded when an exception occurs..did i
finally get my answer?

From:	Wilco Dijkstra
Subject:	Re: Doubt about interrupt handling in AT91
Date:	Tue, 11 Jan 2005 20:41:31 GMT

"Mayank Kaushik" wrote in message
news:1105460232.386475.77260@f14g2000cwb.googlegroups.com...
> ah, i also got this from the arm architecture manual:
> ----
> When an IRQ is detected, the following actions are performed:
> R14_irq = address of next instruction to be executed + 4
> ----
> also, since PC contains the address of the current instruction + 4, i

No.

In ARM state the PC contains the address of the current instruction + 8.
In Thumb state it is current instruction + 4.
On an interrupt the CPU calculates the correct value for R14_irq
by adding a value to the PC. This is 0 for ARM, 2 for a 16-bit Thumb
instruction and 4 for a 32-bit Thumb-2 instruction...

> think the nut is trying to say that PC goes into R14_irq...if we reduce
> this by 4, voila, we get to the next instruction in sequence...it fits!

Yes, you can either subtract 4 from LR before pushing LR in the
interrupt handler, or alternatively do this at the end when returning
from the interrupt.

> but what happens to the other instructions in the pipeline...if i
> remember correctly, they are discarded when an exception occurs..did i
> finally get my answer?

See my other post.

Wilco

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 07:39:16 -0800

Hi, Tauno

> If you want to run the interrupt handler body in C,
> your assembly language layer (called shim by ARM) has
> to return to the user mode register set, but with
> system privileges, thus the system mode. If you do this,
> you can structure the code to work without an IRQ level
> stack.

Could you elaborate on why i need to change the mode to use the C
interrupt handler..why cant i use the same interrupt mode stack, by
first saving all registers before branching off to the C function, then
popping them off on return? And why should we require system
priviledges here?

thanx
Mayank

From:	Wilco Dijkstra
Subject:	Re: Doubt about interrupt handling in AT91
Date:	Tue, 11 Jan 2005 19:26:57 GMT

"Mayank Kaushik" wrote in message
news:1105457956.821264.181520@f14g2000cwb.googlegroups.com...
> Hi, Tauno
>
> > If you want to run the interrupt handler body in C,
> > your assembly language layer (called shim by ARM) has
> > to return to the user mode register set, but with
> > system privileges, thus the system mode. If you do this,
> > you can structure the code to work without an IRQ level
> > stack.
>
> Could you elaborate on why i need to change the mode to use the C
> interrupt handler..why cant i use the same interrupt mode stack, by
> first saving all registers before branching off to the C function, then
> popping them off on return? And why should we require system
> priviledges here?

You can - if you don't require nested interrupts. A non-nested
interrupt function can use IRQ mode without a problem and call
C. The only thing to think about when using C is that you need to
have enough stackspace reserved on the IRQ stack. Since the
user stack is generally larger, using system mode (which uses the
user mode stack) means that you can keep the IRQ stack tiny.

>oops, sorry! Bill has already replied to this...that it would take lots
>of time to store the regs/..additionally in the other mode we have lots
>of new instructions available..

No, Bill was talking about about a different interrupt model which
is not used by current ARMs - I think most of us got confused by
that.

Note the same number of instructions are available in system and IRQ
mode. When you switch to C you always have to save R0-R3,IP and LR,
so there is no difference whether you use system mode or IRQ mode.

Wilco

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 09:02:20 -0800

now i am really at my wit`s end..:-(
i got the foll from the app note on interrupt handling on the atmel`s
site:
this is whats done in the pre-canned libraries, made available by
atmel, before switching to sys mode:

>"When an interrupt is managed by the core, R14_irq and SPSR_irq are
automatically overwritten >without being saved: it is mandatory to save
these registers before re-enabling the IRQ line and to >restore them
before exiting the interrupt management routine. Moreover, if the
interrupt treatment >performs function calls (Branch with Link),
R14_irq is used. In this case, IRQ can not be re-enabled >while the
core is in IRQ mode. It is mandatory to first change the mode of the
core. In order to keep all >exceptions available, the SYSTEM mode must
be used."

i dont get it...why do we need to change the mode?? bill mentioned that
saving link regs to the stack would increase interrupt latency..but a
look at the code provided in the same document for changing modes shows
this:

>;- Adjust and save LR of current mode in current stack
>sub r14, r14, #4
>stmfd sp!, {r14}
>;- Save SPSR and r0 in current stack
>mrs r14, SPSR
>stmfd sp!, {r0, r14}

as u can see, the nut is saving the link addr and the spsr to the
stack..this opposes the latency argument put forward. as for new
instructions being available, isnt the irq mode also a privileged
mode??
help!! :-(

From:	Wilco Dijkstra
Subject:	Re: Doubt about interrupt handling in AT91
Date:	Tue, 11 Jan 2005 20:29:59 GMT

"Mayank Kaushik" wrote in message
news:1105462940.471308.40160@c13g2000cwb.googlegroups.com...

> i dont get it...why do we need to change the mode?? bill mentioned that
> saving link regs to the stack would increase interrupt latency..but a
> look at the code provided in the same document for changing modes shows
> this:
>
> >;- Adjust and save LR of current mode in current stack
> >sub r14, r14, #4
> >stmfd sp!, {r14}
> >;- Save SPSR and r0 in current stack
> >mrs r14, SPSR
> >stmfd sp!, {r0, r14}
>
> as u can see, the nut is saving the link addr and the spsr to the
> stack..this opposes the latency argument put forward.

The common definition for interrupt latency is the number of
cycles between receiving an interupt to executing the first
instruction in IRQ state. This is effectively the hardware
part of interrupt latency. This is the most important latency
as this is something you can't change once you've chosen a
particular CPU. There is also a software side to it, which
depends on the implementation of the interrupt handlers.

The above instructions are part of the interrupt handler and
so they do not count as latency caused by hardware. They
do however increase the time taken before you execute the
actual interrupt handling code - ie. they increase the software
interrupt latency. Interestingly while nested interrupts make
the best case a little slower, they makes the worst-case better
as you avoid disabling higher priority interrupts while
processing a lower priority one.

The goal is generally to minimise the hardware latency so
that software can do whatever it likes. However the software
latency can be non-trivial and that is why architecture version 6
added the new instructions SRS, RFE and CPS to reduce the
time spent saving registers and swapping from IRQ mode to
system mode (and back).

Another commonly used mechanism to improve software latency
is to avoid having to figure out which interrupt was triggered.
A Vectored Interrupt Controller (VIC) allows a CPU to branch
directly to the specific code that handles a particular interrupt
rather than branching to a common interrupt handler which
has to find this out in software (and for complex systems this
can take a lot of cycles). It also deals with priorities, so an
interrupt handler can be preempted by a higher priority interrupt.

The final aspect of interrupt latency is the cost on the code that
was interrupted. Since CPUs use pipelines, some amount of
work has to be thrown away in order to deal with an interrupt
as quickly as possible. Older ARMs always complete instructions,
thereby increasing interrupt latency if the current instruction takes
a long time to complete. Modern ARMs will abandon instructions
mid-way and reexecute them after an interrupt. This lowers the
worst-case interrupt latency but means more cycles are wasted
in the code that was interrupted.

Hope that helps!

Wilco

From:	William Munns
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 17:16:22 GMT

"Mayank Kaushik" wrote in
news:1105462940.471308.40160@c13g2000cwb.googlegroups.com:

>
>>"When an interrupt is managed by the core, R14_irq and
>>SPSR_irq are
> automatically overwritten >without being saved: it is
> mandatory to save these registers before re-enabling the
> IRQ line and to >restore them before exiting the interrupt
> management routine. Moreover, if the interrupt treatment
> >performs function calls (Branch with Link), R14_irq is
> used. In this case, IRQ can not be re-enabled >while the
> core is in IRQ mode. It is mandatory to first change the
> mode of the core. In order to keep all >exceptions
> available, the SYSTEM mode must be used."
>
> i dont get it...why do we need to change the mode?? bill
> mentioned that saving link regs to the stack would increase
> interrupt latency..but a look at the code provided in the
> same document for changing modes shows this:

because the LR belongs to the mode, so if you stay in IRQ mode
and then re-enable interrupts, then BL, then another interrupt
goes off the LR_irq (which holds your return address for the
BL) will be overwritten by the return address from the second
interrupt. Changing to system mode ensures that the return
address from the BL is stored in another LR

>
>>;- Adjust and save LR of current mode in current stack
>>sub r14, r14, #4
>>stmfd sp!, {r14}
>>;- Save SPSR and r0 in current stack
>>mrs r14, SPSR
>>stmfd sp!, {r0, r14}
>
> as u can see, the nut is saving the link addr and the spsr
> to the stack..this opposes the latency argument put
> forward.
> help!! :-(

If you don't want to enable IRQ's then you don't have to mode
switch or save the SPSR, if you don't BL then you don't have
save the LR_irq. The ARM processor gives you this choice and
saves silicon by not pushing the registers onto the stack

> as for new instructions being available, isnt the
> irq mode also a privileged mode??

Yes, saying this was misleading, but I ignored it earlier as
it is a tangent.
The reason you switch into system rather than USER is you need
to return from the interrupt, to do this you need access to
the LR_irq or the SP_irq (if you stacked the LR) which y9ou
can only get in IRQ mode, and you cannot change mode from USER
state except by causing an exception (eg. SWI / data abort /
undefined instruction)

From:	Mayank Kaushik
Subject:	Re: Doubt about interrupt handling in AT91
Date:	11 Jan 2005 09:39:12 -0800

Thanx, Will..i was thinking about it, and the same answer as above
popped in my head..i headed here to post it, and found your reply!

Yes, it all makes sense now..in fact, the foll lines in the code save
the state of the SYSTEM mode when they enter it from the IRQ mode, so
that two BLs in nested interrupt handlers do not clash:

>;- Save used registers and LR_usr in the System/User Stack
>stmfd sp!, {r1-r3, $reg, r12, r14}

Also, thanx for the foll note..im new to all this, so this wudve taken
time to dawn on me:
> The reason you switch into system rather than USER is you need
> to return from the interrupt, to do this you need access to
> the LR_irq or the SP_irq (if you stacked the LR) which y9ou
> can only get in IRQ mode, and you cannot change mode from USER
> state except by causing an exception (eg. SWI / data abort /
> undefined instruction)

Now i can die a happy man :-D

From:	Bill Pringlemeir
Subject:	Re: Doubt about interrupt handling in AT91
Date:	10 Jan 2005 15:07:51 -0500

On 10 Jan 2005, prehistorictoad2k@yahoo.com wrote:

> I am confused about why we need to change the mode or the ARM core
> from irq to sys..the atmel notes mention that the link register and
> the spsr would be overwritten if another interrupt occurs..in that
> case, why can we not just push the values of the above registers the
> stack, and stay in the same mode?

You could put the values on the stack. However, this would consume
several bus cycles to transfer to memory. The registers are faster,
so the IRQ, sys will execute faster. Also, when you transfer to
interrupt or system mode, there are more instructions that are
available. Ie, most mcr, etc. that allow you to maniputlate the MMU.
With this mode mechanism, it doesn't matter if system or user mode was
interrupted. This is common to almost all CPUs I know. The shadowed
registers just make things faster (unless you have to look at
them...).

> also, when an interrupt occurs, the value stored in the register r14
> is PC +4..whys the 4 added??

The interrupt occurs after the instruction completes (in most cases).
If it was not incremented, then you would run the same instruction
twice. This is really bad if the instruction was a system call; you
would have a recursive loop.

One exploit in Phrack uses the SWI and self-modifying code to confuse
the SWI handler as to what the exact instruction had been called with.
The hope is a range check can be avoided. The ARM also does not have
a seperate 'X,R, and W' permissions in the MMU so there is no way to
protect against this. Allowing a user program "writeable memory" will
let them create the exploit; you could delay the range check in the
SWI handler.

fwiw,
Bill Pringlemeir.

--
Remember, if you smoke after you're doing it too fast. - Woody
Allen