Re: [avr-gcc-list] Stuckness with ATTiny15 program and avr-gcc

[Ned Konz]

On Jan 8, 2005, at 2:41 PM, Bruce D. Lightner wrote:

> Ned Konz wrote:
>
> > Note that an updated version of Bruce's init routine for the 3.4 GCC 
> > shouldn't init the stack, as GCC does this at the top of main() now. 
> > Because of this, you have to define __stack. I used a modified 
> > version of Bruce's init.S that looks like this:
>
> I was only setting the stack pointer to "fool" my home-grown AVR 
> emulator.  It doesn't really know about RAM-less AVRs.  (Those two 
> instruction are my "spares" when I use up all the bytes in the program 
> memory. :-)

That's easier than trying to make GCC's optimization better to fit your 
code in...

> Pray tell, where does "main()" get the stack initialization code that 
> I see in your mixed listing!
It appears to come from GCC, nowdays.

> What AVR programmer are you using?
An STK500, and using the programmer that comes with AVRStudio 4. Which 
I run under VMWare, because my machine runs Linux, but that's another 
story.

>  Note that the code you are using reads the internal oscillator 
> calibration byte from the last byte of program memory (i.e., location 
> 0x3ff).  This location is set to 0xff after you erase the chip.  Does 
> *your* programmer read the OSCAL value from the chip and then place 
> that value in the last byte of program memory space as part of the AVR 
> programming sequence?
Yes. The Atmel programmer remembers fuses, and where to store the 
OSCCAL byte. I'm telling it to put the byte in location 1023.

> If not, your internal oscillator will be *way off* and you may or may 
> not see any characters.
I'm using my Agilent mixed-signal oscilloscope for debugging; I don't 
trust the oscillator until I see the timing on the scope.

> (Hyperterm is [in]famous for not showing anything unless the 
> characters it receives are perfect.)
I think that's maybe the Windows comms API, but it's been a while since 
I've done serial programming (or any programming) on Windows.
> Also, exactly what are the "fuse byte" values you are using?
RSTDISABL programmed; BOD not enabled, SPI disabled. I'm using serial 
HV programming.

> I'm also worried about your use of the RESET~ line for I/O.  Are you 
> certain that you have set the fuses properly to enable your firmware 
> to use of this pin for I/O?  (I've never done this myself.)  Is it 
> possible that if this is in fact *not* enabled for I/O use, does 
> driving the pin low with your firmware cause the chip to reset!!??
I'm sure that the fuse is set; prior versions of the program have in 
fact sent characters successfully. So I know the method and board is 
OK. I don't believe that if you don't have the RSTDISABL programmed 
that driving it low causes the chip to reset, though.

> May I suggest a very simple test program that uses something other 
> than the RESET~ line as your next debugging step?
Since I've had prior versions working, I think I've eliminated the 
things that I could test with that program. However, I've not tried it 
with the new init code yet.

Thanks,
Ned