I am a big fan of the Arduino environment because of its simplicity, ease of use, and user community.  I like to use it for many of my projects so this means I must design around the Atmel ATmega MCUs to be compatible with the IDE. When you get a new commercial Arduino development board, a bootloader is already programmed on the chip.  This bootloader enables the IDE to download code over the serial port on the device rather than through the SPI interface. When you click the Download Code button on the IDE, the ATmega is briefly reset, and the bootloader code runs looking for indication that new code needs to be programmed.  The IDE then sends the new code to the UART on the ATmega from a serial port on the computer, usually via a USB-to-TTL converter.

If you are making your own Arduino-compatible hardware and you don’t purchase already-programmed chips, then you will need to program the chips with an Arduino serial bootloader first to be able to use the standard IDE.  There are various ways of doing so and they are well documented (for the most part).  The Arduino software installation comes with bootloader code ready to be programmed onto your target device.  The bootloader code has different flavors to match the different variants in ATmega chips, such as flash size and crystal frequencies.  I personally use the Arduino as ISP method to program the bootloader because I can use it with my existing Arduino board and not have to purchase a stand-alone AVR programmer.

I have an older Arduino Diecimila which I use as my programmer and I put the new chips on a breadboard which is on an Adafruit Proto Shield.  I have the necessary pins wired up from the shield headers to the breadboard and also included the necessary crystal and reset resistor (see here: burning the bootloader).  This setup works pretty well and lets me quickly and easily swap out the chip to be programmed.  It’s not as easy as this, but I already had all the necessary hardware.

I recently ran into a couple issues trying to use this Arduino as ISP method while programming the bootloader on chips for my ColorNode project. First, I kept getting a “not in sync” error when it tried to run the bootloader process. After digging around, I found this site which suggested installing ~ 110Ω worth of resistance between the programmer’s Reset line (Arduino board header closest to power jack) and +5V.  The method is also discussed and explained here. Basically, when the IDE connects to download the bootloader code via the Arduino board programmed as the AVR programmer, that board get’s reset due to the way the auto-reset circuitry works.  Pulling the Reset line to +5V with a much lower resistance prevents this from happening and screwing up the bootloader programming process.

Once I resolved that issue I was able to successfully program the bootloader onto some ATmega328P chips (I chose the regular Duemilanove /w ATmega 328 as the board). I had also purchased up some ATmega328 (non-P) chips because they were cheaper and readily available from DigiKey. The main difference is the process technology where the P indicates their PicoPower technology and is best suited for low-power applications. Since I’m not running off batteries in my application, it doesn’t really matter. The code is compatible with either device and the Arduino IDE doesn’t differentiate between the two when doing the serial programming.

When I attempted to use the above process to program the bootloader on the ATmega328 chips, I ran into my second issue. When I ran the bootloader process I got an “Expected signature for ATMEGA328P is 1E 95 0F” error. Although the two chips are nearly identical and, from the code space aspect are identical, they have different part identification signatures. These signatures need to match those setup in the ISP configuration, specifically the avrdude.conf file. Page 302 in the full datasheet shows that the ATmega328 has a device signature of 0x1E 0×95 0×14 while the signature for the ATmega328P is 0x1E 0×95 0x0F. I found this posting on the arduino forums that talks about it more. Once I changed that setting the bootloader programmed correctly and both the P and non-P versions were able to be serially programmed with the IDE using the standard process.