Posted on May 17, 2011 at 12:55Hi STOne-32,
Thanks for your kind words
🙂 [LR = 0xFFFFFFF1]
Fault occurred in an exception handler.
[PC = 0x08000E4C]
Is that part of hard fault handler?
[Stacked_PC value = 0]
I guess this is the caused.
Somehow an interrupt handler stack frame
got courrupted so the return address is 0.
When exception return is carried out, it got
INVSTATE fault because T bit is 0 (ARM state).
[Stacked_LR = 0x08005587] (code shown in image)
It is likely that this part of code is executed shortly
before it crash. When BL.W messagehandler is executed
0x08005587 is store onto LR. But the actual fault
can happen sometime after that. The fault could be in
a different interrupt handler (if the crash is caused
by an exception handler), or could be in the
messagehandler.
It might worth checking the stack memory location
to see if any address values were pushed onto the stack
during the interrupt handler. It might give you hint
where the problem is. But then, the address value
could be put there ages ago and not related to the fault.
Have you tried interrupt trace feature in RealView-MDK?
It would be useful to know what is the interrupt sequence
just before the crash:
http://www.keil.com/support/man/docs/ulink2/ulink2_trace_exception.htm From the stacked_PSR it shown exception 35 (SPI1 ?).
Maybe worth checking what exceptions have higher priority
than this exception, than we can narrow down the cause of the
issue to small number of exception handlers.
When the code is compiled with different optimizations,
it is possible that some local variables were kept in
the register bank rather than being put onto the stack.
As a result, the stack corruption problem could disappear
when you use higher level of optimization.
(even the memory location is corrupted, it might not be
causing problem as less stack is used).
Yes, getting a full instruction trace would be ideal.
Cheers
Joseph
[ This message was edited by: joseph.yiu on 10-12-2008 17:17 ]
