Are these Atmega328 dead?

[sumpm1]

Hello first post. I bought 2 Atmega328p-pu and 2 Atmega328-pu from mouser.com. I have Arduino Duemilanove. I bought 4 of these so I could experiment with building my own Arduinos. So I first loaded the bootlader onto all 4 of these using a breadboard, and Optiloader loaded onto my Arduino. I followed this tutorial exactly: http://www.3guys1laser.com/blog-burn-bootloader-blank-atmega328atmega328p-arduino-uno

So here is the result. After burning bootlader, I replace the atmega328 in my arduino with my purchased ones and try to run the "blink" example. With ONE of the 2 atmega328p that I bought, everything works fine. With the other, I get this error:

avrdude: stk500_getsync(): not in sync: resp=0x00

I also get that error when trying each of the atmega328-pu. I have read probably 100 topics about this "out of sync" issue and there is not an exact consensus on the cause. Some say the atmega328 is "dead" or the fuse is burnt, others say you have chosen the wrong port or arduino board in the ide. But I can upload and run sketches on two of my atmega328's.

So does this mean that 3 of my 4 atmega's are "dead?"

[johnwasser]

Does optiLoader report success when you burn the bootloader again?

[sumpm1]

Does optiLoader report success when you burn the bootloader again?

Well I had only loaded optiLoader onto Dueminalove and then was burning each chip with Arduino powered through usb, I wasn't using the serial monitor. So my only "monitor" of what optiLoader is doing is the led. And I'm not yet sure how to use the serial monitor, since I am just going through usb; this is my first forte with Arduino and AVR in general... iamnewb haha.

I am trying to figure out how I can use the sesrial monitor just through usb.

[johnwasser]

I am trying to figure out how I can use the sesrial monitor just through usb.

After you upload the optiLoader sketch, click on the Serial Monitor button.  This brings up a window that will show you whatever text the Arduino is sending.  Make sure the baud rate (at the bottom of the Serial Monitor window) is set to the baud rate used by the sketch (in the Serial.begin(baudrate); line, typically in setup()).

[n3qik]

Did you use the 16 MHZ crystal & caps
I am using a different stand-alone ISP programmer. Had troubles loading the Bootloader at times. Made some adjustments to the xtal wires, now works every time.

[sumpm1]

Did you use the 16 MHZ crystal & caps

Yes I used 16mhz and 22pf caps. I also tried it without those, still same result. What change did you make?

Okay figured out the serial monitor, and here is what optiloader outputs to serial monitor:

Code: [Select]


OptiLoader Bootstrap programmer.
2011 by Bill Westfield (WestfW)

Target power on! ...
Starting Program Mode [OK]

Reading signature:950F
Searching for image...
 Found "optiboot_atmega328.hex" for atmega328P
 Start address at 7E00
 Total bytes read: 502

Setting fuses for programming
 Lock: 3F FFE000  Low: FF FFA000  High: DE FFA800  Ext: 5 FFA400

Programming bootloader: 512 bytes at 0x3F00
 Commit Page: 3F00:3F00
 Commit Page: 3F40:3F40
 Commit Page: 3F80:3F80
 Commit Page: 3FC0:3FC0

Restoring normal fuses
 Lock: 2F FFE000

Target power OFF!

Type 'G' or hit RESET for next chip


So does that mean that optiLoader successfully wrote the bootloader? Or was the fuse locked and optiLoader couldn't change it?

[westfw]

Yes, that should have been a successful bootloader burn.

100 topics about this "out of sync" issue and there is not an exact consensus on the cause.

The "out of sync" message is a bit like a young child telling his parents "it hurts!"; it can have a lot of different causes, and the uploader doesn't even have the vocabulary to be clearer about what it is that isn't working.  :-(

If optiloader is still sending that sort of dialog to the serial port when you try to re-program the bootloader, it means that your chips are NOT dead.  At least, not totally dead (they could have the serial port pins dead, for instance.)  Optiloader has slightly better diagnostics than the Arduino IDE "upload" command.  Since it has an entirely different communications path to the AVR, it's not going to be very good at figuring out why the upload fails, though.

[sumpm1]

Yes, that should have been a successful bootloader burn.

If optiloader is still sending that sort of dialog to the serial port when you try to re-program the bootloader, it means that your chips are NOT dead.  At least, not totally dead...

Well it is at least good news that something is going right. I am a total newb. So I just sit here wondering "am i doing any of this right?" So a little confidence at least!

The "out of sync" message is a bit like a young child telling his parents "it hurts!"; it can have a lot of different causes, and the uploader doesn't even have the vocabulary to be clearer about what it is that isn't working.  :-(

I like the analogy. So is there any standard "troubleshooting sequence" when dealing with "out of sync" errors?

Thanks.

[johnwasser]

So is there any standard "troubleshooting sequence" when dealing with "out of sync" errors.

"Out of sync" often means that the bootloader is not responding properly.  This can mean that the bootloader is not receiving commands, is not sending replies, or the sending or receiving is not successful for other reasons such as baud rate mismatch.  Another possibility is that the Auto Reset isn't working.  Once control goes to the installed sketch the bootloader doesn't get control (and thus can't respond to upload requests) until there is a reset.

After you burn the optiboot bootloader in the 386 chip and install it in your Duemilanove are you selecting "Arduino UNO" under Tools->Boards?  The Duemilanove uses an older bootloader with a slower baud rate.

[sumpm1]

After you burn the optiboot bootloader in the 386 chip and install it in your Duemilanove are you selecting "Arduino UNO" under Tools->Boards?  The Duemilanove uses an older bootloader with a slower baud rate.

No, I was still choosing "Arduino Dueminalove" under Tools->Boards. And the one fresh Atmega328p that I got working is uploading sketches using that setting once installed in the Dueminalove. But I will try selecting Uno and reporting back.

Another possibility is that the Auto Reset isn't working.

Would this be an issue with my Dueminalove, or the newly bootloaded Atmega328p?

Thanks for answering all these newb questions guys. I've gotta take my knocks to get started.

[sumpm1]

After you burn the optiboot bootloader in the 386 chip and install it in your Duemilanove are you selecting "Arduino UNO" under Tools->Boards?  The Duemilanove uses an older bootloader with a slower baud rate.

Oh bite it, that worked, my sketch uploaded and ran no errors XD XD XD XD. I owe you 12 beers!

Newbies worldwide rejoice.

[sumpm1]

Okay I'd really like to mark this topic "solved," and add some remarks for those that are having resp=0x00 or resp=0x15 issues.

But here is my next question. So I now have one working Atmega328p that needs the IDE to be set to "Uno," and I have 2 working Atmega328p that need the IDE to be set to "Dueminalove," and 2 working Atmega328 that need to be set to "Uno."

Should I now load optiBoot using optiLoader onto those 2 Atmega328p chips? Is there any advantage? Possible risk?

I am so happy right now though.

[westfw]

Should I now load optiBoot using optiLoader onto those 2 Atmega328p chips? Is there any advantage?

Faster uploading, 1.5k more flash space for your sketch, Uno compatibility, and "all your boards will be the same."

[n3qik]

Load the same boot loader on all of the chips !!!
This way all the program/uploading of the sketches will be the same.

[sumpm1]

Load the same boot loader on all of the chips !!!
This way all the program/uploading of the sketches will be the same.

Done, it didn't take much convincing. The sketches do seem to upload more quickly than with the original Dueminalove.