[avr-gcc-list] Freaky code wraparound...

[Dan Larson]

Hello all,

I am working on some LCD code for the ATMega103 on the STK-300 board
and I am having a very strange problem that is proving to be extremely
difficult to debug without an ICE.

What appears to be happening is that the device is continually executing 
up until a certain point and then ending up back at the reset entry point.

I have verified that I am correctly turning off the watch dog in my _init_()
routine and there are no interrupts being generated. Also, in my _init_()
code I dump the high or low byte of the stack pointer to the LEDs depending
on which push button is pressed. Through the same mechanism I can also dump
MUCSR to determine the cause of the reset.

So far I have been able to determine the following:

1) It is *not* an external (BOR), or a power-up reset.

2) It is *not* the watchdog reset. I have the watch dog disabled and I also 
inserted a spin-loop (infinite loop) at the beginning of main() to see
if the watchdog would trip. It doesn't.

3) The stack pointer appeared to be in an underflow condition when I dumped
it to the LEDs.  The preamble code of main sets the stack at 0x0FF7 and the
value displayed on the LEDs was 0xFF8.

So far all of the clues point to stack corruption. This is most likely a bug
in the compiler output because I never manipulate the stack directly and I am
not overflowing any arrays or local variables. I highly suspect that the 
_init_()
routine is reached by the program counter "wrapping around" to zero, since the
previous two bytes pulled from the stack (SP & SP+1) are not zero, indicating 
that
address 0x0000 was not popped off the stack while returning from some function.

Now for the "Freaky" part. The problem has never occurred in the AVR Studio 
simulator.
I can spot no errors in the assembly output of the compiler that would corrupt 
the
stack. The code under the simulator never reaches 0x0000 after reset nor do 
stack
contents get written to out of context. I had originally been using the memory 
mapped
LCD interface on the STK-300 board, but I switched to using PORT I/O instead, 
suspecting
that there may have been some timing issues screwing up the CPU. I am now using 
4-bit
mode on PORTA (yes, the external memory is turned off). I have scoped and 
verified
the timing on the LCD to be correct. I can even get it to display a few 
characters
some times, depending on how I arrange the code, but it always eventually goes 
wild 
and ends up at the reset vector again before the main() code can finish.

I even borrowed my friends STK-300 kit and got the same results, thus ruling out
a bad CPU.

Does anyone know of any compiler bugs or have any tips the help me track this 
problem down? I am using the win32 2.97 version of the compiler , downloaded 
from 
AVR-FEAKS.

If I had access to an ICE, I am sure I would have found the problem by now, but 
I am 
at my wits end with this.


Thanks!

Dan