Got all my parts this afternoon and spent some time trying to get things working. Everything was going great, and then the programmer stopped talking to the avr. Lots of time on here and adafruit and google and and the 378 page Atmel ATMegaX data sheet, and I can't figure out what to try next.

ATmegaXX8 board + zif + 168 chip
USPtinyISP
3 x AA battery pack
16 MHz Crystal and Cap Set

the AVCC, AVREF and AGND straps are in place
PD4 - resistor - LED - gnd (leftover LED and resistor from here)
a cap at C4, 47 pF (only one I could find - should it be 100 nF?)

and that's it. the "provide power" jumper in the programmer is removed. when it was working, the red programmer led would illuminate and my led would turn off when writing flash and writing fuses. the setup was working well, and I was just figuring out how to get it all working. had a flashing led which was supposed to be 1Hz but wasn't quite right, period was too short.

and then... I played with some fuse setting, and the whole thing stopped working. what to do? I now get:

and

but - it reports inconsistent device signatures from the avr!

so the hardware is not deterministic. ick! any thoughts?

I'm using CrossPack-AVR-20100115. I fiddled with fuse settings, in particular the brown out detector. it wouldn't work with 4V, but finally started working with 2.7V. my battery pack is putting out 4.1V, with three freshly charged 2650 mAh Duracell AA's. here is the a bit more output...

OK, found exactly where I screwed things up. (love infinite scroll buffer on mac!) this worked.

then edited Makefile and wanted lfuse to be 0x9F but miscalculated as 0xBF. !!!!!!

and then it got funky

then sadness.

I think you haven't said what efuse setting you left it with.

It looks like you may have programmed it to require the external crystal and have a 4.3 V brownout level-- that's pretty high, and won't work with 4.1 V output. Grab some *very fresh* alkaline AAs to put it over 4.3 V just long enough to reprogram that to 2.7 V. If that doesn't work, carefully check the soldering at your crystal and caps.

Also: be damned careful when playing with the fuses. It's possible to render your chip no-longer-ISP-programmable with the wrong choices. I recommend using the fuse calculator: http://www.engbedded.com/fusecalc/

Hmm, the Makefile created by avr-project has no mention of efuse. So apparently I haven't changed it.

That fuse tool is awesome, thanks! Much easier than trying to cobble it together by poring over the device reference document. But after reading the reference, the options make more sense. Fun learning this.

I pulled the battery and jumpered the USBtinyISP to provide power. Seems to be working again. Cool.

One last question - if I select the "Divide clock by 8 internally; [CKDIV8=0]" option, and I have a 16 MHz crystal, should I specify 2 MHz as the chip speed in my Makefile? OK, tried it and I still don't get 1Hz flash. Well, something to work on.

> I pulled the battery and jumpered the USBtinyISP to provide power.

Yes, that will work too. I should have remembered to suggest it.

One last question - if I select the "Divide clock by 8 internally; [CKDIV8=0]" option, and I have a 16 MHz crystal, should I specify 2 MHz as the chip speed in my Makefile? OK, tried it and I still don't get 1Hz flash. Well, something to work on.

Yes, that will give a 2 MHz system clock. But the makefile doesn't *necessarily* need to know this; all that a makefile entry about your system clock will do is define a variable that *could* be used elsewhere in your code. So... depends what that other code does.

If you really want to get a feel for the system clock and its behavior, you might consider (a) learning about the timers from the datasheet-- timer 1 is 16 bit and has prescalers available -- or (b) using some known-good LED blinking code set up for 16 MHz, like that from the Arduino codebase. (You can use the Arduino stand-alone makefile to compile, or use the USBtiny as the defined programmer within the Arduino program.)

OK, so it seems the flashing LED had nothing to do with the code I wrote. The period of the flash was how long the chip would work until it reset. Seems the batteries just aren't cutting it. Running from USB power via the programmer is fine. And yes, for a 16 MHz crystal with divide by 8 enabled, F_CPU should be 2000000UL.

Specifying the clock speed is used in <util/delay.h> and friends. Does a busy-wait loop, and needs to know this to figure out how many iterations.

Of course, a timer would be better. One step at a time.

Hi -

I am hoping that you might give me some advice.

I'm a newbie at this, I have made a few sketches with an Arduino board and have some other projects in mind that would involve installing the CPU without the Duemilanove board.
I purchased a few ATMEGA328s and a USBtiny programmer with an ATMEGAxx8 target board as a programmer (which sounds to me like the same setup you have). I have been able to write the Arduino bootloader to a cpu using the Duemilanove, Arduino IDE, and the USBtiny which leads me to believe that the USBtiny is working. But, when I try the same thing with the ATMEGAxx8 board, it it gives me the rc=-1 error. All the help files say that it has to be a wiring error. I've ohmed out the target board, and it seems to be set up correctly. I have 0.1uf cap from vcc to gnd, a 10K resistor from reset to vcc, a resistor LED from sck to ground, agnd to ground, and aref and avcc to vcc. I also tried adding a 16MHz crystal and caps. I've tried powering from the USBtiny, and from an external 5v supply. A pre-loaded cpu blinks the LED when plugged into the target board. Clearly I've missed something that should have been very obvious to me. I don't know where to go next. Any suggestions?

RGRDS

nav

The "rc=-1" error is a blanket error that covers a whole lot of possible problems. You'll sometimes get this with very obvious things like power not applied, or the connector backwards on the ISP cable connection. Sometimes I've found that you need to unplug the board/programmer and plug it back in and things work okay-- this happens if the computer detects too much power use on the USB port.

Most of your setup sounds okay. The only thing that sounds worrisome is the LED on the SCK line; you might try removing that to see if it has an effect.

Thank you, I'll give it a try.