After spending a bunch of time chasing down bits and pieces of information, I thought I would take the time to summarize it in one place for the benefit of the next poor soul who decides to burn an optiboot (Uno) bootloader into a new chip.
My system:
Target chip = ATmega328p MCU, 16MHz
Chip will be used in an Arduino clone (custom board, similar to 2009)
The clone board will have the FTDI chip for serial comm's
I used Windows XP and the 0022 IDE for burning the new bootloader
I welcome corrections, but this is what I think I learned from the experience:
The optiboot hex file that was shipped with IDE 0022 is buggy. On my system, it caused my DIP 328p to lose its sketch every time power was switched off. Turns out this was a known problem -- just not by very many people, including me. Get the updated optiboot_atmega328.hex and optiboot_atmega328.lst files here (github).
Using an Arduino as an AVR ISP (In-System Programmer) is mostly right. Like many have already noted, it is missing step 1.5. This is the step where you disable autoreset on the Arduino being used as the ISP device (see more below).
In my case, I set up a standard Arduino 2009 as the ISP. Not clear immediately to me was the fact that you first must set the IDE for the board being used as the ISP (2009 in my case). Then you upload the ArduinoISP sketch to that board. Only after you have uploaded the sketch can you disable the autoreset and change the Board selection in the IDE.
I used a ZIF socket on a breadboard to hold the target MCU. Contrary to my initial impressions from the tutorial page, if you go the breadboard route you must use the clock crystal configuration. The configuration shown that uses the internal clock will not give you a chip that can be used on a 16MHz board.
To disable autoreset on the 2009, I followed DisablingAutoResetOnSerialConnection and connected its reset pin to +5V through a 120 ohm resistor. Some people have written that disabling autoreset is not necessary. They are liars [ummmmm, they might be right now -- see update below.]
Add the LED's to your breadboard that are described in the comments in the ArduinoISP sketch. They are really handy to have when you're trying to figure out what's wrong.
After you have uploaded the ArduinoISP sketch to your ISP board, then go into the Tools menu of the IDE. Select the Board that will give you the bootloader you want in the target MCU sitting on your breadboard. In my case, I wanted the Uno optiboot bootloader, so I selected "Arduino Uno" from the Board menu.
Go to the Tools menu again, and this time select "Burn Bootloader", then "w/ Arduino as ISP." If you have disabled autoreset, and you have everything wired up correctly, then you will see the "heartbeat" LED (see no. 6 above) start to beat and the "programming" LED turn steady on. You will also see the RX/TX LED's flashing on your ISP board. After the programming LED goes off, you should see a message in the IDE telling you that the bootloader has been burned.
Once the ISP board has had the ArduinoISP sketch uploaded, you can burn additional chips in subsequent sessions by going directly to "Burn Bootloader." Just be sure and select the correct bootloader version from the Board menu.
Jim
UPDATE 17-Dec-2011: I recently read on this forum, and have now confirmed, that Uno boards with the latest version of optiboot do not require physically disabling autoreset to work with ArduinoISP. Also, I've "upgraded" my original breadboard setup and mounted the components on the ISP Shield 2.0 bare PCB from Evil Mad Science. Heckuva handy board for $3.
JimG is absolutely correct. When using the setup that Jim is showing, you absolutely need the 120 ohm resistor between reset and +5. Just yesterday, I used this fix on a Duemilanove that I was using as a programmer to burn a bootloader.
I have a Duemilanove with pins added for burning bootloaders using this method. Pop out a programmed chip, pop in a blank one.
Took a few minutes to desolder the X3 holes & put in pins, and to download/unzip/relocate the needed files.
Has worked well for me.
Am not aware that Uno has this capability.
Since this is the first valid result for my search, I'm going to reply here.
This tutorial works for Arduino Uno (R2).
The only different thing is, instead of using a 120 ohm resistor between the RESET pin and 5V, I used a 0.1uf/100nF capacitor.
But I have a remaining question, if someone has the appropriate knowledge/experience to answer.
If I wish to program an ATmega328 (not "p"), the response from the Arduino application is:
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Double check chip, or use -F to override this check.
So, how can I override this check (since the Arduino app doesn't allow me to input any flags for avrdude), or change the file/code that's returning this error?
After another search with different terminology (something like "burn opti 328"), I found OptiLoader by WestfW, which is a sketch + header file that turns your Arduino into an automatic programmer for the ATmega 8, 168, 328, 328p:
And it works with the circuit shown above, without any resistors / capacitors on the reset pin.
Thanks for the reply. I am guessing that change needs to be in the "optiboot" file. However, the file is showing poor punctuation using notepad so, I am going to have to study it.
On a great note, I have bootloaded 2 of my 10, Small Arduinos! Pretty cool!
I just had to get my head around the bootloading process.
@ CrossRoads, I will try to get some pictures to you tomorrow.
OK got Notepad ++ installed and found the file that Adilinden directed me to. I then found the area with the signature bytes. Here is what part of it looks like.
#------------------------------------------------------------
# ATmega328P
#------------------------------------------------------------
part
id = "m328p";
desc = "ATMEGA328P";
has_debugwire = yes;
flash_instr = 0xB6, 0x01, 0x11;
eeprom_instr = 0xBD, 0xF2, 0xBD, 0xE1, 0xBB, 0xCF, 0xB4, 0x00,
0xBE, 0x01, 0xB6, 0x01, 0xBC, 0x00, 0xBB, 0xBF,
0x99, 0xF9, 0xBB, 0xAF;
stk500_devcode = 0x86;
# avr910_devcode = 0x;
signature = 0x1e 0x95 0x0F;
pagel = 0xd7;
bs2 = 0xc2;
chip_erase_delay = 9000;
pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1",
"x x x x x x x x x x x x x x x x";
chip_erase = "1 0 1 0 1 1 0 0 1 0 0 x x x x x",
"x x x x x x x x x x x x x x x x";
timeout = 200;
Sorry, my post was cut short. Earlier this week I assembled two Duemilanove boards. I used the 328-PU instead of the 328P and encountered that exact same error message. I was trying to burn the bootloader using an AVR ISP MKII and the Arduino IDE. No idea which bootloader this installed, whether it optiboot or something else. I've been unsuccessful in trying to find the exact thread that described the workaround. I did have to change the signature bytes in the /Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf file. To be exact, there is a 328P section in that file that specifies the signature.
The thread stated that avrdude needs to match that signature bytes to burn the boot loader. Once the boot loader has been burnt then the signature bytes need to be changed back in order to program sketches. Apparently the bootloader does not check the actual signature byte of the chip, but reports its stored value. Since the 328P bootloader is burnt into the 328 chip, it will then report the 328P signature when sketches are programmed.
Please note that the background information is statements I remember from reading elsewhere. I don't know nearly enough about bootloaders or Ardunio IDE to claim this to be truth. However, from working with the 328-PU chips I can say with certainty, that changing the signature bytes in avrdude.conf worked to burn the bootloader, and that it had to be reverted back before I was able to upload a sketch.
cyclegadget:
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Double check chip, or use -F to override this check.
PM westfw, I bet he can add the non-P versions in his documented release for everyone to use.
Hmm. Non-P version already added to optiLoader.
The trouble with everything else (optiboot Makefile, boards.txt) is that they've been confusing "328" and "328P" since day one. (that is, they SAY "ATmega328" and then include the signature for 328P.)
It would be so nice if all of those AVR were supported in the stock Arduino distribution. I am trying to figure out how to add custom boards and processors to the Arduino environment. I am particularly interested in the atmega32u4 and the atmega1284p...
You need to update a few files:
avrdude.conf
boards.txt
pins_arduino.c
and get the correct 'core files', I used the ones here for '1284 chips with the -0022 IDE. www.avr-developers.com
Arduino 1.0 may include some of what's needed, unless you don't like the pinout selected.
For example, see this thread where I question the use of pins as seen in other places for the ATMega32U4/Leonardo. http://arduino.cc/forum/index.php/topic,78631.0.html #20, #43 in particular
In your step 1, what do you do with the new bootloader files (.hex, .lst) that you download from Github?
BTW, after disabling auto Reset per your step 5 (120 Ohm resistor between +5 & RESET), the bootloader (version unknown) has now been successfully burned onto the uC. I was using a Duemilanove board and Arduino 023 (not 1.0).
Once there is closure on a workable/agreed upon process to burn the bootloader onto a new ATmega328P, we need to petition the arduino.cc web team to correct the tutorials.
[ummmmm, they might be right now -- see update below.]