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

[Keith Gudger]

Maybe this is way too obvious, but is there any chance your Watch Dog is
firing?

On Tue, 26 Oct 2004, Theodore A. Roth wrote:

> 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
> 
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
>