Forums

ARM Data Abort exception debugging

Started by imperialbeach August 31, 2009
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 - 


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