Electronic – AVR Flash Writing Error

I believe I may have found a two part solution for my particular problem. I currently own an Arduino Diecimila (which has the ATMEGA168 with the problem) and also a new Arduino Nano 3.0. I went ahead and flashed the Arduino Nano with the ArduinoISP firmware. I then picked up 3 28 Pin ATMEGA328P DIP chips for $5.00 each at the local electronics store.

I used the ArduinoISP to flash one of the virgin chips with the Arduino Firmware using the above link with a crystal. I plan to now flash one of the other ATMEGA328Ps with the High Voltage Programmer firmware. This chip along with a bit of wiring on a breadboard should allow me to reset all of the fuses on the original ATMEGA168. Once that is done, I will be able to use the Arduino Nano to reprogram the chip.

Since the ATMEGA328Ps only cost $5 each, my end goal is to setup one 328 as an Arduino ISP programmer, setup the 168 as a HV Programmer, keep one 328 chip in my current Arduino Diecimila (upgrade!!), and I'll have one left over for whatever. I can then either switch chips on the Diecimila or build out a real board for the ISP and HV Programmer boards.

I still have not tested the JTAG ICE MKII yet with a logic/oscilloscope. Not sure if it is the root of the problem or not. I will address this issue after I build the HV Programmer.

I will report back on the success/failure of the HV Programmer. I just need to go get a few more 1K resistors to pull it off. Anyone ever tried the HV Programmer? Any other suggestions? If nothing else, hope this helps someone.

Have you been able to verify at all that the device is responding at any level? You say you programmed the fuse bits, but have you been able to verify that they were actually changed?

According to the data sheet:

The SPI Serial Programming instructions will not work if the communication is
out of synchronization. When in sync. the second byte ($53), will echo back
when issuing the third byte of the Programming Enable instruction. Whether
the echo is correct or not, all four bytes of the instruction must be
transmitted. If the $53 did not echo back, give RESET a positive pulse and
issue a new Programming Enable command.

Perhaps you could see if you can test this, either with an option to/modification of avrdude, or even just looking with a scope to see if the miso line is wiggling at all?

I'd think the question has aged enough that if it's still an issue, ordering any older chips from the atmega8/16/32 family to test the programmer would be worthwhile.

The atmel literature seems to imply that the change are primarily fab process related, so it's possible that the new device might be more noise sensitive in some respects.