Electronic – ATMega644PA possibly bricked by setting fuses with avrdude

atmegaavrdudefuse-bitslinux

I have been programming an ATMega644PA with avr-gcc and avrdude on linux for a little while with no problems. Well until I decided to change some fuses. I had been using the option for avrdude -p ATMEGA644P for programming the chip even though the chip is ATMega644PA.

After reading the data sheet (and reading the fuses on the chip) I did the following

avrdude -v -c avrispmkII -p ATMEGA644P -P usb -U lfuse:w:0x63:m

The chip would no longer communicate. I realized after that the problem may have been that I set the bits for external clock rather than crystal oscillator but even with using an ATTiny to generate a 1MHz signal to the proper pin on my Mega644, I still get nothing.

Any ideas as to why the chip is unresponsive? Could it be that using avrdude's definition for the P version of the chip rather than the PA version is the cause?

And finally, What can I do to rescue my chip? Ive heard that it may be possible with High voltage programming or JTAG. Would I be able to do that with an STK500?

Best Answer

Nope, your 0x63 setting on the lfuse byte has selected the internal 128kHz oscillator as the clock source. (bytes 3..0 are CKSEL, see table 7.1 on p.28 of the ATmega644 datasheet where 0011 is 'Internal 128 kHz RC Oscillator'). This is nice and low power, but it means that your programmer likely isn't clocking itself slowly enough to program your device. I'm not familiar with either avrdude or the STK500, but this is where your problem is coming from.

However, it will be difficult for you to brick your chip, because you've got the STK500, which can do high voltage programming and rescue it from most situations. As I've never used the device, I'll defer to the many other threads where others have posted problems and solutions for AVR fuse settings. There's also one here on Chiphacker (see my comment.)

Next time, this fuse setting calculator is a nice resource. It's fantastic that you read the datasheet, and tried to calculate what you wanted yourself, but the tool makes it much easier.

BTW, what were the fuses set to before you made the change?

Edit: Looks like the 'A' option just indicates that it's not a member of the "*P*ico Power" series, so that shouldn't make a difference.

Related Solutions

Electronic – Arduino Diecimila (ATMEGA168) + JTAG ICE MKII Hell..Did I Fry the Chip

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.

Electronic – AVR Atmega32 flash verification error

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.

Best Answer

Related Solutions

Electronic – Arduino Diecimila (ATMEGA168) + JTAG ICE MKII Hell..Did I Fry the Chip

Electronic – AVR Atmega32 flash verification error

Related Topic