Lpc2000

Peter,

Thanks for the insights.  If I remove the 'offending' statement, the
problem goes away.  Does that still sound like a possible linker script
error to you?

Curt

-----Original Message-----
From: Peter [mailto:pmaloy@...] 
Sent: Sunday, March 07, 2004 11:09 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: Possible gcc bug?


--- 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.





 
Yahoo! Groups Links