Re: [ECOS] Unexpected exception handler call (0x53)

[Nick Garnett <nickg at ecoscentric dot com>]

"Dirk Broer" <dbroer@matrics.com> writes:

> We are newly targeting an arm based board.
> 
> We get often an exception with 0x53 (83).

Do you really mean exception 0x53? The ARM only has four possible
exceptions, numbered 1-4. Do you actually mean an interrupt?
Alternatively, maybe the stack is being corrupted and the exception
value is bogus.

> 
> Back Trace shows nothing interesting.

What does backtrace actually show?

> 
> How best to proceed to track this down?  Where would the Âreal stack have
> been stored?  Was it stored?

Exceptions are usually handled on the stack that was current when the
exception occurred. In GDB the value of r13 will be the SP of the
interrupted code. If this is a real exception then looking at what the
insruction pointed to by the PC was doing should give you a clue.

> 
> My best guess is that this is the default handler, should we override this?
> Again, can we recover the stack?

You should not need to do anything special here. The default VSR
should dump you into the GDB stubs, which is what you want.

> 
> We are still implementing Âinfo threads and right now have no direct
> visibility on the state of other threads in the system.
>

Why do you need to implement the "info threads" stuff? This is all
handled by target-independent code, HAL ports should not need to do
anything about this.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss