Re: [avr-gcc-list] Freaky code wraparound... (UPDATE)

[Dan Larson]

I am now convinced that there is either a bug in the avr-gcc compiler
or a problem with the Atmega103 / STK-300 board.

I changed the MCU target to at90s8515, recompiled, and downloaded the
code to an 8515 on my STK-500 board. The very same code worked flawlessly
with no unwanted code wraparound or spurious resets. I stripped all debug
code from my _init_() routine, but left the code to disable the watchdog
timer. I added a very long loop, in which the counter was displayed on the
LCD. It ran perfectly. 

When I changed the target back to the atmega103 and downloaded the code
to the stk300 board, once again it failed by repeatedly wrapping to the 
reset vector after displaying only one character on the first line.

The "freaky" and annoying part of this whole problem is that I can never
get the code to misbehave under the AVR Studio simulator. This convinces
me that there is something about the code generated by the compiler and / or
the atmega103 / stk300 that the simulator doesn't reproduce.

Without an ICE, I am afraid that I will never solve this problem and thus
cannot trust the atmega103, STK-300, or the compiler.

Can anyone provide further insight on what may be happening here?

So far I have had suggestions about the voltage on the board sagging and
the possibility of a bug with the Z register rolling over to zero causing
a reset.

I can rule out the Z register problem because the only place that the Z 
register 
is used is loading up initialized globals from the flash memory in the startup
code. It always "resets" or "wraps" well after that.

I am pretty sure that the VCC on the board is OK because I was getting nice
crisp edges on the waveforms on my 'scope and they were rising all the way to 
5V.
I also scoped the power and reset lines and found nothing unusual happening
as the code kept vectoring to 0x0000 every 27ms or so.... (well past the reset
of the LCD anyway..)

I have also updated to the latest win32 release as downloaded from AVR-Freaks.

The code I have will run fine when targeted for an 8515 and gets "freaky" when
targeted for an m103.

I would be glad to mail the files upon request if someone would like to take
a look at what is going on...

Thanks!

Dan



On Tue, 27 Mar 2001 14:02:29 -0600, Dan Larson wrote:

>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
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>avr-gcc-list mailing list
>address@hidden
>http://avr.jpk.co.nz/mailman/listinfo/avr-gcc-list
>