>Wim Lewis wrote:
>> In article <KumdnWrtRrDy9gHXnZ2dnUVZ_hednZ2d@giganews.com>,
>> imperialbeach <jrucker@ssccorp.com> wrote:
>>> I'm getting a Data Abort error - I'm trying to get the full call
>>> stack. The IAR tools say the call stack is unavailable after the
>>> exception, is there a way around this? I'm thinking I could
>>> painfully recostruct stack frames, but it seems like the tool should
>>> do it -
>>
>> It does seem like the tool ought to do that for you...
>>
>> Maybe you could put an interrupt-return sequence in the exception
>> handler, and single-step past it in the debugger? Or some similar
>> trick to get back to the interrupted context so that the debugger
>> will extract a backtrace for you? I haven't used the IAR tools.
>
>That is an approach I have used before.  Make sure you adjust the return

>address properly.  When an ARM interrrupt or exception occurs, the return
PC 
>is set to the instruction after the one that was interrupted.  You need
to 
>subtract 4 from the return address to get to the right place.
>
>Write a routine like this, break on it, and single step back to where the

>exception occured.  That should let you see all the registers and the
stack 
>frame at the time the exception occurred.
>
>Scott 
>
>
>

Thanks everyone - it did turn out that I could set the PC and SP using the
LR from the exception, so I can see the call stack. Now I just have to
catch the actual exception, so I can track back - 	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com

Wim Lewis wrote:
> In article <KumdnWrtRrDy9gHXnZ2dnUVZ_hednZ2d@giganews.com>,
> imperialbeach <jrucker@ssccorp.com> wrote:
>> I'm getting a Data Abort error - I'm trying to get the full call
>> stack. The IAR tools say the call stack is unavailable after the
>> exception, is there a way around this? I'm thinking I could
>> painfully recostruct stack frames, but it seems like the tool should
>> do it -
>
> It does seem like the tool ought to do that for you...
>
> Maybe you could put an interrupt-return sequence in the exception
> handler, and single-step past it in the debugger? Or some similar
> trick to get back to the interrupted context so that the debugger
> will extract a backtrace for you? I haven't used the IAR tools.

That is an approach I have used before.  Make sure you adjust the return 
address properly.  When an ARM interrrupt or exception occurs, the return PC 
is set to the instruction after the one that was interrupted.  You need to 
subtract 4 from the return address to get to the right place.

Write a routine like this, break on it, and single step back to where the 
exception occured.  That should let you see all the registers and the stack 
frame at the time the exception occurred.

Scott

In article <KumdnWrtRrDy9gHXnZ2dnUVZ_hednZ2d@giganews.com>,
imperialbeach <jrucker@ssccorp.com> wrote:
>I'm getting a Data Abort error - I'm trying to get the full call stack. The
>IAR tools say the call stack is unavailable after the exception, is there a
>way around this? I'm thinking I could painfully recostruct stack frames,
>but it seems like the tool should do it - 

It does seem like the tool ought to do that for you...

Maybe you could put an interrupt-return sequence in the exception handler,
and single-step past it in the debugger? Or some similar trick to get back
to the interrupted context so that the debugger will extract a backtrace for
you? I haven't used the IAR tools.

-- 
   Wim Lewis <wiml@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1
  "We learn from history that we do not learn from history." -Hegel

On Sep 1, 9:30=A0am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> Op Tue, 01 Sep 2009 02:31:43 +0200 schreef imperialbeach =A0
> <jruc...@ssccorp.com>:
>
> > I'm getting aDataAborterror - I'm trying to get the full call stack. =
=A0
> > The IAR tools say the call stack is unavailable after the exception, is=
 =A0
> > there a way around this? I'm thinking I could painfully recostruct stac=
k =A0
> > frames,
> > but it seems like the tool should do it -
>
> Read the ARM Architectural Reference Manual. =A0It will tell you importan=
t =A0
> things like the fact that exception processing mode uses a different stac=
k =A0
> pointer than user mode.
>
> --
> Gemaakt met Opera's revolutionaire e-mailprogramma: =A0http://www.opera.c=
om/mail/

The majority of Data Abort exceptions I've debugged were caused by
uninitialized pointers.

What I usually do to see the call stack is to stop execution before
the exception occurs (which might be tricky in some cases).
- First you need to pinpoint the instruction causing the data abort
exception:
"A Data Abort Exception means that your application is trying to read
or write an illegal memory location. You can calculate the illegal
memory location using by subtracting 8 from the value in R14 (link
register). Subtracting 8 adjusts for the instruction queue giving you
the address of the instruction that caused this exception."
- Then you should create a watchpoint (related to the illegal memory
access), so the debugger stops execution at that point.


For more information on how to calculate the illegal memory location,
check http://www.keil.com/support/docs/3080.htm.
There is also a cool article on embedded.com about data abort
exception handlers : http://www.embedded.com/shared/printableArticle.jhtml?=
articleID=3D192202641

Op Tue, 01 Sep 2009 02:31:43 +0200 schreef imperialbeach  
<jrucker@ssccorp.com>:
> I'm getting a Data Abort error - I'm trying to get the full call stack.  
> The IAR tools say the call stack is unavailable after the exception, is  
> there a way around this? I'm thinking I could painfully recostruct stack  
> frames,
> but it seems like the tool should do it -

Read the ARM Architectural Reference Manual.  It will tell you important  
things like the fact that exception processing mode uses a different stack  
pointer than user mode.




-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/