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

[Bruce D. Lightner]

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. :-)

Pray tell, where does "main()" get the stack initialization code that I 
see in your mixed listing!

> Oddly, in turning the circuit off and on it did start emitting serial that 
> looked sorta right -- once. (repeated "73 00\r\n", which indicates that the 
> correction loop wasn't running, since the 00 is the OCR1A number and should 
> have been increased because the ADC wasn't reading anything). At least this 
> tells me that the timing and logic of the serial output routine is probably 
> correct.

What AVR programmer are you using?  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?

If not, your internal oscillator will be *way off* and you may or may not 
see any characters.  (Hyperterm is [in]famous for not showing anything 
unless the characters it receives are perfect.)  Here's what your code 
does on startup...

static inline void
initializeClock(void)
{
    OSCCAL = pgm_read_byte_near(0x3ff); // read OSCCAL byte from last 
location in memory
}



Also, exactly what are the "fuse byte" values you are using?

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!!??

May I suggest a very simple test program that uses something other than 
the RESET~ line as your next debugging step?

Best regards,

Bruce

--
 Bruce D. Lightner
 Lightner Engineering
 La Jolla, California
 Voice: +1-858-551-4011
 FAX: +1-858-551-0777
 Email: address@hidden
 URL: http://www.lightner.net/lightner/bruce/