[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dan Larson
Subject: [avr-gcc-list] Freaky code wraparound...
Date: Tue, 27 Mar 2001 14:02:29 -0600

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 
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 
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 
I can spot no errors in the assembly output of the compiler that would corrupt 
stack. The code under the simulator never reaches 0x0000 after reset nor do 
contents get written to out of context. I had originally been using the memory 
LCD interface on the STK-300 board, but I switched to using PORT I/O instead, 
that there may have been some timing issues screwing up the CPU. I am now using 
mode on PORTA (yes, the external memory is turned off). I have scoped and 
the timing on the LCD to be correct. I can even get it to display a few 
some times, depending on how I arrange the code, but it always eventually goes 
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 

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]