Hi
I am trying to unterstand what the LPC interrupt vector table seting are
regarding the VicAddress.
>From an LPC2348 crt.s
b _start
ldr pc, _undf
ldr pc, _swi
ldr pc, _pabt
ldr pc, _dabt
nop ldr pc, [pc,#-0x120]
ldr pc, _fiq
What ldr pc, [pc,#-0x120] actually do ?
>From an LPC2294 crt.s
ldr PC, Reset_Addr
ldr PC, Undef_Addr
ldr PC, SWI_Addr
ldr PC, PAbt_Addr
ldr PC, DAbt_Addr
nop
ldr PC, [PC,#-0xFF0]
ldr PC, FIQ_Addr
Why is the second has an offset #-0xFF0
Is this to do with where the address of VICVectAddr register in each type of LPC
Parts?
Regards
Jean-Jacques
Interrupt Vector Table
Started by ●September 28, 2009
Reply by ●September 28, 20092009-09-28
Jean-Jacques
> What ldr pc, [pc,#-0x120] actually do ?
pc := [pc-0x120]
> Why is the second has an offset #-0xFF0
>
> Is this to do with where the address of VICVectAddr register in each type of LPC Parts?
That's it. Check both manuals, they describe it.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
> What ldr pc, [pc,#-0x120] actually do ?
pc := [pc-0x120]
> Why is the second has an offset #-0xFF0
>
> Is this to do with where the address of VICVectAddr register in each type of LPC Parts?
That's it. Check both manuals, they describe it.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
Reply by ●September 28, 20092009-09-28
In both examples, in general, the two instructions in question calculate an
address and read the value at that address and store that value in the program
counter (PC).
Assuming both sets of code reside at address 0, then for the second example we have:
0000 0000: ldr PC, Reset_Addr
0000 0004: ldr PC, Undef_Addr
0000 0008: ldr PC, SWI_Addr
0000 000C: ldr PC, PAbt_Addr
0000 0010: ldr PC, DAbt_Addr
0000 0014: nop
0000 0018: ldr PC, [PC,#-0xFF0]
0000 001C: ldr PC, FIQ_Addr
-the address of the current instruction in question = 0x18
-the value of the program counter is then 0x18 + 8 = 0x20
(the value of the PC is always the address of the current instruction +8, except in thumb mode)
-the offset (-0XFF0) is then added, 0x20-0xFF0 = 0x20 + 0xFFFF F010 = 0xFFFF F030
0XFFFF F030 is the address of the VicVectAddr
So in summary, the instruction essentially loads the value of the VicVectAddr (which should be the address of your interrupt service routine) into the program counter.
The first example is essentially the same, except the offset is -0x120 instead of -0xFF0.
So the calculated address to load the PC from would be:
0x20-0x120 = 0x20 + 0xFFFF FEE0 = 0xFFFF FF00 which, according to the LPC23XX user manual, is the address of the VICAddress or Vector address register.
So the two examples do essentially the same thing. The only real difference is the offset values which is a result of the different architectures as you suspected.
--- In l..., "jdauchot" wrote:
>
> Hi
>
> I am trying to unterstand what the LPC interrupt vector table seting are regarding the VicAddress.
> From an LPC2348 crt.s
>
> b _start
> ldr pc, _undf
> ldr pc, _swi
> ldr pc, _pabt
> ldr pc, _dabt
> nop ldr pc, [pc,#-0x120]
> ldr pc, _fiq
>
> What ldr pc, [pc,#-0x120] actually do ?
>
> From an LPC2294 crt.s
>
> ldr PC, Reset_Addr
> ldr PC, Undef_Addr
> ldr PC, SWI_Addr
> ldr PC, PAbt_Addr
> ldr PC, DAbt_Addr
> nop
> ldr PC, [PC,#-0xFF0]
> ldr PC, FIQ_Addr
>
> Why is the second has an offset #-0xFF0
>
> Is this to do with where the address of VICVectAddr register in each type of LPC Parts?
>
> Regards
>
> Jean-Jacques
>
Assuming both sets of code reside at address 0, then for the second example we have:
0000 0000: ldr PC, Reset_Addr
0000 0004: ldr PC, Undef_Addr
0000 0008: ldr PC, SWI_Addr
0000 000C: ldr PC, PAbt_Addr
0000 0010: ldr PC, DAbt_Addr
0000 0014: nop
0000 0018: ldr PC, [PC,#-0xFF0]
0000 001C: ldr PC, FIQ_Addr
-the address of the current instruction in question = 0x18
-the value of the program counter is then 0x18 + 8 = 0x20
(the value of the PC is always the address of the current instruction +8, except in thumb mode)
-the offset (-0XFF0) is then added, 0x20-0xFF0 = 0x20 + 0xFFFF F010 = 0xFFFF F030
0XFFFF F030 is the address of the VicVectAddr
So in summary, the instruction essentially loads the value of the VicVectAddr (which should be the address of your interrupt service routine) into the program counter.
The first example is essentially the same, except the offset is -0x120 instead of -0xFF0.
So the calculated address to load the PC from would be:
0x20-0x120 = 0x20 + 0xFFFF FEE0 = 0xFFFF FF00 which, according to the LPC23XX user manual, is the address of the VICAddress or Vector address register.
So the two examples do essentially the same thing. The only real difference is the offset values which is a result of the different architectures as you suspected.
--- In l..., "jdauchot" wrote:
>
> Hi
>
> I am trying to unterstand what the LPC interrupt vector table seting are regarding the VicAddress.
> From an LPC2348 crt.s
>
> b _start
> ldr pc, _undf
> ldr pc, _swi
> ldr pc, _pabt
> ldr pc, _dabt
> nop ldr pc, [pc,#-0x120]
> ldr pc, _fiq
>
> What ldr pc, [pc,#-0x120] actually do ?
>
> From an LPC2294 crt.s
>
> ldr PC, Reset_Addr
> ldr PC, Undef_Addr
> ldr PC, SWI_Addr
> ldr PC, PAbt_Addr
> ldr PC, DAbt_Addr
> nop
> ldr PC, [PC,#-0xFF0]
> ldr PC, FIQ_Addr
>
> Why is the second has an offset #-0xFF0
>
> Is this to do with where the address of VICVectAddr register in each type of LPC Parts?
>
> Regards
>
> Jean-Jacques
>
Reply by ●September 29, 20092009-09-29
Thanks for the excellent explanation abrpbay12...
I have one more question though.
What's the reason behind
>> *(the value of the PC is always the address of the current instruction
+8, except in thumb mode)*
-Ananda
On Mon, Sep 28, 2009 at 1:53 PM, abrpbay12 wrote:
> In both examples, in general, the two instructions in question calculate an
> address and read the value at that address and store that value in the
> program counter (PC).
>
> Assuming both sets of code reside at address 0, then for the second example
> we have:
>
> 0000 0000: ldr PC, Reset_Addr
> 0000 0004: ldr PC, Undef_Addr
> 0000 0008: ldr PC, SWI_Addr
> 0000 000C: ldr PC, PAbt_Addr
> 0000 0010: ldr PC, DAbt_Addr
> 0000 0014: nop
> 0000 0018: ldr PC, [PC,#-0xFF0]
> 0000 001C: ldr PC, FIQ_Addr
>
> -the address of the current instruction in question = 0x18
> -the value of the program counter is then 0x18 + 8 = 0x20
> (the value of the PC is always the address of the current instruction +8,
> except in thumb mode)
> -the offset (-0XFF0) is then added, 0x20-0xFF0 = 0x20 + 0xFFFF F010 > 0xFFFF F030
> 0XFFFF F030 is the address of the VicVectAddr
>
> So in summary, the instruction essentially loads the value of the
> VicVectAddr (which should be the address of your interrupt service routine)
> into the program counter.
>
> The first example is essentially the same, except the offset is -0x120
> instead of -0xFF0.
> So the calculated address to load the PC from would be:
> 0x20-0x120 = 0x20 + 0xFFFF FEE0 = 0xFFFF FF00 which, according to the
> LPC23XX user manual, is the address of the VICAddress or Vector address
> register.
>
> So the two examples do essentially the same thing. The only real difference
> is the offset values which is a result of the different architectures as you
> suspected.
> --- In l... , "jdauchot"
> wrote:
> >
> > Hi
> >
> > I am trying to unterstand what the LPC interrupt vector table seting are
> regarding the VicAddress.
> > From an LPC2348 crt.s
> >
> > b _start
> > ldr pc, _undf
> > ldr pc, _swi
> > ldr pc, _pabt
> > ldr pc, _dabt
> > nop ldr pc, [pc,#-0x120]
> > ldr pc, _fiq
> >
> > What ldr pc, [pc,#-0x120] actually do ?
> >
> > From an LPC2294 crt.s
> >
> > ldr PC, Reset_Addr
> > ldr PC, Undef_Addr
> > ldr PC, SWI_Addr
> > ldr PC, PAbt_Addr
> > ldr PC, DAbt_Addr
> > nop
> > ldr PC, [PC,#-0xFF0]
> > ldr PC, FIQ_Addr
> >
> > Why is the second has an offset #-0xFF0
> >
> > Is this to do with where the address of VICVectAddr register in each type
> of LPC Parts?
> >
> > Regards
> >
> > Jean-Jacques
> >
>
I have one more question though.
What's the reason behind
>> *(the value of the PC is always the address of the current instruction
+8, except in thumb mode)*
-Ananda
On Mon, Sep 28, 2009 at 1:53 PM, abrpbay12 wrote:
> In both examples, in general, the two instructions in question calculate an
> address and read the value at that address and store that value in the
> program counter (PC).
>
> Assuming both sets of code reside at address 0, then for the second example
> we have:
>
> 0000 0000: ldr PC, Reset_Addr
> 0000 0004: ldr PC, Undef_Addr
> 0000 0008: ldr PC, SWI_Addr
> 0000 000C: ldr PC, PAbt_Addr
> 0000 0010: ldr PC, DAbt_Addr
> 0000 0014: nop
> 0000 0018: ldr PC, [PC,#-0xFF0]
> 0000 001C: ldr PC, FIQ_Addr
>
> -the address of the current instruction in question = 0x18
> -the value of the program counter is then 0x18 + 8 = 0x20
> (the value of the PC is always the address of the current instruction +8,
> except in thumb mode)
> -the offset (-0XFF0) is then added, 0x20-0xFF0 = 0x20 + 0xFFFF F010 > 0xFFFF F030
> 0XFFFF F030 is the address of the VicVectAddr
>
> So in summary, the instruction essentially loads the value of the
> VicVectAddr (which should be the address of your interrupt service routine)
> into the program counter.
>
> The first example is essentially the same, except the offset is -0x120
> instead of -0xFF0.
> So the calculated address to load the PC from would be:
> 0x20-0x120 = 0x20 + 0xFFFF FEE0 = 0xFFFF FF00 which, according to the
> LPC23XX user manual, is the address of the VICAddress or Vector address
> register.
>
> So the two examples do essentially the same thing. The only real difference
> is the offset values which is a result of the different architectures as you
> suspected.
> --- In l... , "jdauchot"
> wrote:
> >
> > Hi
> >
> > I am trying to unterstand what the LPC interrupt vector table seting are
> regarding the VicAddress.
> > From an LPC2348 crt.s
> >
> > b _start
> > ldr pc, _undf
> > ldr pc, _swi
> > ldr pc, _pabt
> > ldr pc, _dabt
> > nop ldr pc, [pc,#-0x120]
> > ldr pc, _fiq
> >
> > What ldr pc, [pc,#-0x120] actually do ?
> >
> > From an LPC2294 crt.s
> >
> > ldr PC, Reset_Addr
> > ldr PC, Undef_Addr
> > ldr PC, SWI_Addr
> > ldr PC, PAbt_Addr
> > ldr PC, DAbt_Addr
> > nop
> > ldr PC, [PC,#-0xFF0]
> > ldr PC, FIQ_Addr
> >
> > Why is the second has an offset #-0xFF0
> >
> > Is this to do with where the address of VICVectAddr register in each type
> of LPC Parts?
> >
> > Regards
> >
> > Jean-Jacques
> >
>
Reply by ●September 29, 20092009-09-29
--- In l..., Ananda Regmi wrote:
>
> What's the reason behind
> >> *(the value of the PC is always the address of the current instruction
> +8, except in thumb mode)*
>
Read Chapter A1 "Introduction to the ARM Architecture" in the ARM Architecture Reference Manual for fundamental information of this sort. If you do not already have a copy - download it now. Google for "ARM architecture reference manual" to find it.
--
Chris Burrows
CFB Software
Armaide v2.1: LPC2xxx Oberon-07 Development System
http://www.cfbsoftware.com/armaide
>
> What's the reason behind
> >> *(the value of the PC is always the address of the current instruction
> +8, except in thumb mode)*
>
Read Chapter A1 "Introduction to the ARM Architecture" in the ARM Architecture Reference Manual for fundamental information of this sort. If you do not already have a copy - download it now. Google for "ARM architecture reference manual" to find it.
--
Chris Burrows
CFB Software
Armaide v2.1: LPC2xxx Oberon-07 Development System
http://www.cfbsoftware.com/armaide
Reply by ●September 30, 20092009-09-30
Hi,
This is because of pipe lining...When you are executing current instruction, the next instruction (current instruction+ 4) is getting decoded and the instruction after that (current instruction+ 8) is getting fetched.
Regards,
Himanshu Patel
--- On Wed, 9/30/09, cfbsoftware1 wrote:
From: cfbsoftware1
Subject: [lpc2000] Re: Interrupt Vector Table
To: l...
Date: Wednesday, September 30, 2009, 12:54 AM
--- In lpc2000@yahoogroups .com, Ananda Regmi wrote:
>
> What's the reason behind
> >> *(the value of the PC is always the address of the current instruction
> +8, except in thumb mode)*
>
Read Chapter A1 "Introduction to the ARM Architecture" in the ARM Architecture Reference Manual for fundamental information of this sort. If you do not already have a copy - download it now. Google for "ARM architecture reference manual" to find it.
--
Chris Burrows
CFB Software
Armaide v2.1: LPC2xxx Oberon-07 Development System
http://www.cfbsoftw are.com/armaide
This is because of pipe lining...When you are executing current instruction, the next instruction (current instruction+ 4) is getting decoded and the instruction after that (current instruction+ 8) is getting fetched.
Regards,
Himanshu Patel
--- On Wed, 9/30/09, cfbsoftware1 wrote:
From: cfbsoftware1
Subject: [lpc2000] Re: Interrupt Vector Table
To: l...
Date: Wednesday, September 30, 2009, 12:54 AM
--- In lpc2000@yahoogroups .com, Ananda Regmi wrote:
>
> What's the reason behind
> >> *(the value of the PC is always the address of the current instruction
> +8, except in thumb mode)*
>
Read Chapter A1 "Introduction to the ARM Architecture" in the ARM Architecture Reference Manual for fundamental information of this sort. If you do not already have a copy - download it now. Google for "ARM architecture reference manual" to find it.
--
Chris Burrows
CFB Software
Armaide v2.1: LPC2xxx Oberon-07 Development System
http://www.cfbsoftw are.com/armaide
Reply by ●October 1, 20092009-10-01
Good to know I was of some help Ananda :)
With regards to your question... as Himanshu Patel pointed out, historically, it was because of the ARM7 3 stage pipeline of fetch, decode and execute. However, in later arm versions the stages in the pipeline has been increased.
ARM7: fetch, decode, execute
ARM9: fetch, decode, execute, memory, write
ARM10:fetch, issue, decode, execute, memory, write.
Note the execute stage for the ARM10 is in the fourth stage. The point being, despite the pipeline changes over the ARM versions, the rule of the pc pointing to the currently executing instruction + 8, has been maintained. (Note, each instruction is 4 bytes) Thus, I say, historically, it was related to the pipeline. Now, however, it appears more of a characteristic the designers are maintaining for compatibility issues.
Note that in thumb mode, the PC points to the current instruction + 4. This is because the instructions in thumb mode are only 2 bytes in size.
--- In l..., Ananda Regmi wrote:
>
> Thanks for the excellent explanation abrpbay12...
>
> I have one more question though.
>
> What's the reason behind
> >> *(the value of the PC is always the address of the current instruction
> +8, except in thumb mode)*
>
> -Ananda
>
With regards to your question... as Himanshu Patel pointed out, historically, it was because of the ARM7 3 stage pipeline of fetch, decode and execute. However, in later arm versions the stages in the pipeline has been increased.
ARM7: fetch, decode, execute
ARM9: fetch, decode, execute, memory, write
ARM10:fetch, issue, decode, execute, memory, write.
Note the execute stage for the ARM10 is in the fourth stage. The point being, despite the pipeline changes over the ARM versions, the rule of the pc pointing to the currently executing instruction + 8, has been maintained. (Note, each instruction is 4 bytes) Thus, I say, historically, it was related to the pipeline. Now, however, it appears more of a characteristic the designers are maintaining for compatibility issues.
Note that in thumb mode, the PC points to the current instruction + 4. This is because the instructions in thumb mode are only 2 bytes in size.
--- In l..., Ananda Regmi wrote:
>
> Thanks for the excellent explanation abrpbay12...
>
> I have one more question though.
>
> What's the reason behind
> >> *(the value of the PC is always the address of the current instruction
> +8, except in thumb mode)*
>
> -Ananda
>
