Re: [avr-gcc-list] help debugging resets

[Theodore A. Roth]

On Tue, 26 Oct 2004, David Morrison wrote:

> Hi,

> Is there a way that I can have the reset handler print out the
> module/line number that the MCU was on when it resets?  I am having an
> issue where my board with a ATmega162 is resetting and I can not
> narrow down where it is due to the fact that print statements change
> the behavior.
>
>  Oh, and to make this more difficult the board I am using doesn't
> support the use of Jtag debuggers so it looks like I would have to use
> a completely software driven solution.
>
> Any ideas?

You will have to roll your own for this unless someone else has already
done it and is willing to share.

You could set up a default interrupt handler. In that handler, you can
pop the return address off of the stack and then spit it out a serial
port (adjusted for byte-ordering). After than go into an infinite loop.
This won't catch spurious resets though, only spurious interrupts.

Of the top of my head, I can think of two causes for spurious resets:
using a function pointer that is NULL (e.g. ff->func() when ff->func is
NULL) or jumping (or calling) into code past the end of your program
which will cause the PC to wrap around to the reset vector. I've
experienced both of this (95% of the time it was because of a stack
overflow in a multi-tasking system) and I've never come up with a way to
track it down other than code-examination (which sucks). Using the
jtagice box has never been much help here for me except that I can do a
memory dump of the various task stacks to see if there was an overflow
(which is obvious because I init all the bytes in each stack with 0xaa
at boot time).

You might want to look into using a simulator that can do tracing of
both the stack and the program counter at the minimum. Then you can just
let it run and do a postmortem analysis of the trace.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden