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 :
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/
=A0
=A0
k =A0
t =A0
k =A0
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
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 , Seattle, WA, USA. PGP keyID 27F772C1 "We learn from history that we do not learn from history." -Hegel
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
PC
to
stack
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.