So now I understand that I'm getting a ARM Data Abort exception - I see how to trap the exception itself (a bad address in the STL library), but I would like to walk back up the stack frame before the exception. I'm using the IAR toolchain, and it tells me the call stack is unavailable after the exception - is there a trick way to convince the tool to show me the call stack? Thanks for all the quick help!
+2
A:
if you look at the ARM ARM (ARM Architecture Reference Manual, just google "arm arm"), Programmers Model -> Processor modes and Registers sections. When in abort mode you are priveledged so you can switch from abort to say supervisor and then make a copy of r13, then switch back to abort mode and dump the stack from the copy of r13. Your r14 also tells you where the abort occurred.
I wouldnt be surprised if this abort was from an alignment. Trying to read/write a word with an address with something other than zeros in the lower two bits or a halfword with the lsbit of the address set. Actually if you take the link register and a dump of the registers (r0-r12) since abort and user/supervisor use the same register space, you can look at the instruction that caused the abort and the address to see if it was indeed an alignment problem or something else. Note that the pc is one, two or three instructions ahead depending on the mode thumb or arm that had the abort, if you are not using thumb at all then this nothing to worry about.
dwelch
2009-09-01 00:21:08
Definitely get the armarm if you haven't already. It's an incredible book. The abort can come from alignment and depending on how you set up your mmu/mpu just an illegal address. I use an OMAP based 926ejs core and there are actually registers that will store the abort address so make sure you consult your spec sheet.
ThePosey
2009-09-01 00:36:38
Thanks - I will check if the problem is alignment or a bad pointer. If it's just alignment, can I return from the exception? I do have the ARM Arm, I will be studying it.
Jeff
2009-09-01 15:40:07
I think you need to figure out why it happened. If this is alignment then the trap is helping you not hurting you. Yes, you can just return (to the instruction after the problem) whatever the problem, but the memory access that it needed to perform will not happen and you will likely fail somewhere else because the data you need was not read or written. You can even disable the alignment data aborts but it just makes it that much harder to find the real problem.
dwelch
2009-09-01 17:22:37