Lpc2000

--- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...> 
wrote:
> I've run into a situation that I've had several times before but 
never
> done anything about.  All of the sudden, code that was working (and
> should be working) fine causes a processor data abort exception.
> Before, I've always been able to rearrange the code and have the 
problem
> go away but today I decided I should try to get to the bottom of 
it.
:
<snip>
:
> I'm an arm assembler novice, but it looks like 0000000c is getting
> loaded into r2 and being used to access a memory location, but 
000000c
> isn't a valid memory location.  Alternatively, if I add 360 
decimal to
> pc (37c) I get 4e4 which holds 4ec which seems to point to a valid
> address; OTOH the first variable (0x378+0x160) points to 0x4d8 
which in
> turn points to 0x4f0 which is code in the following routine USBInit
()
> (but this operation appears to execute successfully).  Like I 
said, I'm
> not exactly sure how to interpret the assembler but I do know that 
it is
> causing an exception.

Hi Curt,

I can't tell what's going wrong here. it is screaming 'compiler bug' 
at me - or perhaps linker script error (hmmm... that may be more 
likely?).

One thing I wanted to mention that may help when you're tracking the 
problem down, is that you should remember that because the ARM is a 
pipelined architecture, the program counter is actually pointing 
*two instructions* beyond the currently executing instruction. In 
ARM state, this will be 8 bytes and in Thumb state 4 bytes beyond 
the currently executing instruction.

Because all flavours of ARM have the first three pipeline stages in 
common (Fetch, Decode, Execute), this rule works with any ARM core.

Wandering off-topic, a nice way to use this is in a call to a 
function with an address loaded from a table or computed at run-time:

 mov lr,pc             ; set up return address
 ldr pc,[r4,r5,lsl #2] ; branch to function

In this example, r4 holds the base address of an array of pointers 
to functions, r5 holds the index into the array and is multiplied by 
4 to give the offset from the base of the array to the entry 
containing the required function pointer. Pipelining works to our 
advantage, placing the address of the instruction *after* the ldr pc 
into the link register, which is the correct return address when 
returning from the function.

Good luck with tracking the problem down.

Peter.