bootloading the atmega328-pu

hotshotharry:
So recently i ordered a bunch of atmega chips (atmega328-pu as opposed to the atmega328p pico power series) as i dont need the extra power saving gains so i decided to save myself some money. However I had a heck of a time trying to burn the bootloader on them and it took me several hours to find the info i needed so i thought i would just archive the info for anyone looking for the same. If you have any tips or suggestions please add them as i am still quite new to all of this. The chips loaded in this process seem to work fine ...

Please note this is for the non picopower atmega328-pu chips signature = 0x1e 0x95 0x14 (1E 95 14) vs atmega328p-xx (1E 95 0F)

I tried to load the optiboot and the demillinauve bootloaders via the arduino ide v22 but all i could get was this message - Expected signature for ATMEGA328P is 1E 95 0F Double check chip, or use -F to override this ...

After much searching I found you need to modify the avrdude.conf file ( mac = arduino -show package contents - resources/java/hardware/tools/avr/etc )

Make a backup copy of this file in case something gets messed up.

Open the file with text edit and about 2/3 the way down under atmega 328 find " signature = 0x1e 0x95 0x0F; "

change the 0F to 14 save it and restart the arduino ide, you should now be able to bootload your atmega328-pu chips.

Make sure to change the 14 back to OF and restart when your done loading the bootloaders otherwise it will fail with - Expected signature for ATMEGA328P is 1E 95 14 Double check chip, or use -F to override this ...

Good luck :slight_smile:

I do not understand why I should change back the 14 to 0F ?? Since I am using atmega 328 instead of atmega 328P, so I change the setting and then why I need to change back to atmega 328P setting again since I am using atmega 328 ??

why I need to change back to atmega 328P setting again since I am using atmega 328 ?

Because the IDE does not know about the 328, and the bootloader will be telling it that the chip is a 328P to make up for that. This is "OK" because the 328 and 328P are nearly identical, and certainly identical as far as Arduino is concerned. So the only time you need anything to know about the 328 is when you are burning the bootloader, because in that case the software is reading the chip type directly off of the chip. (thereafter, the IDE reads the chip type from the bootloader, and the bootloader lies.)

I am still very blur about it. When burning bootloader, I have to change the setting..but when uploading code, Atmega 328 is the same as Atmega 328P ? So that is why the bootloader for atmega 328 lies ? Because the IDE recognise only Atmega328P bootloader ?

That's close enough...

Means I am correct ?

I just burned the bootloader in 5 Atmega328 (non-P) in a row using this technique. My ISP was an Arduino UNO R3.

After that, I changed the .conf file back, removed the original 328P from my UNO R3, placed each of the 5 ICs in there and tested every one with 3 simple sketches. They all worked flawlessly.

The funny thing is that in order for the 328(non-P) to work in the UNO R3 (where the 328P was originally), I had to change the file back to its original setting.

Anyhow, I had great success (YOU WIN!) with this! Thanks for the explanation.

I hope that in the next release of the IDE the 328(non-P) and the Atmega1284 are added to repository of boards.

This thread has been very helpful and very confusing at the same time.

I have a Uno R3 loaded w. ArduinoISP wired to a Atmega328-PU (purchased with uno bootloader preloaded) wired on a breadboard. Using 1.02 on 10.5.8.

I have now successfully uploaded sketches to the breadboard, but only after changing the signature in in avrdude.conf from 0x0F to 0x14, else I get the "expected signature" error in avrdude. Everybody else in this thread seems to just need the avrdude.conf fix to burn the bootloader, and can upload sketches without modifications?

I figured my preloaded bootloader might be the cause for this, so i tried to reinstall the bootloader, but via ArduinoISP this always gave me
avrdude: verification error, first mismatch at byte 0x0000
(same setup where uploading sketches works)
I tried with optiLoader, which seems to work ok (I don't know if there is feedback on errors) but the result is the same, still signature errors on sketch upload.

How come my Atmega328-PU sends the different signature?
And why do my bootloading attempts fail?

Heres my setup and my boards.txt:

still signature errors on sketch upload.

Your setup is not correct for uploading sketches USING the bootloader, which would happen using the serial port of the target AVR (and is somewhat difficult to do to a breadboard AVR using an existing Arduino as the usb interface - the usual "upload" path after burning the bootloader is via an FTDI usb/serial cable or dongle.)
What you describe is consistent with having gotten "upload using programmer" to work; this doesn't use the bootloader (and in fact erases the bootloader each time), but does require the permanent change/upgrade to the CPU type in the avrdude.conf file.
I can't explain the failure to verify when burning the bootloader. Exactly which process are you using to burn the bootloader? The IDE's "burn bootloader" or something else? Have you modified boards.txt, or ONLY the avrdude.conf file?

westfw:
What you describe is consistent with having gotten "upload using programmer" to work; this doesn't use the bootloader (and in fact erases the bootloader each time), but does require the permanent change/upgrade to the CPU type in the avrdude.conf file.

Thanks a lot for clearing that up for me.

I feel a little stupid posting in this thread now, as I realize I'm not sure I even need a bootloader. I want to transfer a working arduino sketch into a hardwired version with only the microcontroller, not an arduino board - this seems to work!

I also want to do this with smaller chips (I got an attiny85 too) and I remembered that the bootloading procedure was needed there to set the fuses, so I followed this tutorial but with arduino-tiny cores. Burning the bootloader gives errors (expected?), but I think it worked for the fuses I think it worked for the fuses(If I burn the 8 Mhz bootloader, but then select the 1 Mhz board prior to uploading the blink sketch, the led goes ~ 8 times faster) .

So I guess I'm there - is there anything I am missing out on? It is not clear what advantage the bootloader would give me - debugging via serial maybe?

What is the correct device signature of the Atmega328P-PU?

I tried bootloading it with my bootloaded Atmega328P-PU, but i was getting

avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

, when i made no changes to the avrdude.conf file and the device signature was still 1E 95 0F.

I tried editing the avrdude.conf file entry, of signature from 1E 95 0F to 1E 95 14. It still shows,

avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

Any thoughts?

One of these days I'll have to find out how to get the chip to tell me what it is.
I was able to get it to work but it was so many months ago I can't be sure of details, it can be done with Arduino 0022 and UNO as ISP.

When you install a bootloader on the 328-PU (Non PicoPower) you have to create a new 328 entry in avrdude.conf with the correct signature. You then create a new 328 boards.txt entry pointing to the new 328 device in avrdude.conf, but otherwise using the same details (bootloader, fuses etc) as the 328P entry.

So, this allows you to burn a bootloader and set fuses for 16Mhz external crystal etc, just like for the 328P.

The problem is then when you come to upload a sketch, whether via Upload (Serial and bootloader) or Upload via Progammer (ISP programmer gia ICSP/SPI). If you leave the board type in IDE set to 328 (non P) then you'll find you can't compile and upload.

What you have to do is switch back to telling IDE/avr-gcc/avrdude that it's the normal Uno 328P.

So, you burn bootloader with 328 set as board, but upload with Uno as the board.

Don't forget if it's barebones then you need to do a manual reset after the compile has completed (if using serial via the bootloader).

I think the issue is actually with the (older) version of avr-gcc compiler that Arduino IDE uses. For some reason it doesn't handle the non-P 328 uC, so you have to lie and say it's a 328P.

When you burn the bootloader/set fuses etc, then the signature of the chip is actually read and has to match the signature of a device that avrdude/IDE knows about, to match a bootloader via boards.txt, hence adding a 328 entry to avrdude.conf and boards.txt to get last that hardware check and allow you to get the Uno bootloader into the chip, even if you just use it to set fuses and then reveret to ISP programming afterwards (where you just tell everything it's a normal Uno).

grimreaper:
What is the correct device signature of the Atmega328P-PU?

I tried bootloading it with my bootloaded Atmega328P-PU, but i was getting

avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

, when i made no changes to the avrdude.conf file and the device signature was still 1E 95 0F.

I tried editing the avrdude.conf file entry, of signature from 1E 95 0F to 1E 95 14. It still shows,

avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

Any thoughts?

If it's really an invalid signature, I think it usually tells you what it's getting and what it expects. I think this is a general error due to failure to communicate.

You get that error for various reasons - have you checked your connections? Have you disabled auto-reset? If it's a new chip, you will need a crystal and caps at least until you have the bootloader written (which also sets the fuses).

So a quick question in regards to this thread, if I am getting back a message from avrdude stating the chip is returning 0x000000 or 0xffffff as it's signature should I assume it is trashed? I'm using an Atmega328P-PU and trying to burn a bootloader based on the steps in the Arduino to Breadboard tutorial. I was using the chips to test some simple sketches on a breadboard and they stopped accepting sketch changes so I'm trying to recover them.

if I am getting back a message from avrdude stating the chip is returning 0x000000 or 0xffffff as it's signature should I assume it is trashed?

Maybe. I most often see that when I don't have a correct connection to the chip, such as when a wire pulls out of the breadboard or arduino socket-strip.

Thanks Westfw, I'll double check all my connections to make sure. On a whim I put the chip on an UNO and uploaded the blink sketch to it and it worked. I was then able to upload my sketch again, but I have that 2 second bootloader pause now that I wasn't having before. I'm going to try and reload the bootloader with makefile changes talked about in http://arduino.cc/forum/index.php/topic,37347.0.html.

This method works great for me on arduino 1.0.5, seems to be broken with 1.5.2, though. Anyone figure it out?

There is a solution to this problem
i have made a new "Board" Option in the arduino software
So u do not need to edit again and again to use the atmega328(no P) and atmega328P

You can just select the board name "Arduini Uno w/Atmega328(no P)"

Here is the link to my blog where the procedure is written

The simplest method to use Atmega328 with arduino

There is a solution to this problem

Yeah. NOW there is a solution. In 2013 when the thread was last edited, or 2011 when it first started, the version of the compiler included with the Arduino IDE didn't support the 328 (only the 328P), nor did avrdude.

With a current (1.65+) version of the IDE, it should be pretty trivial. (Much more trivial than the 27MB download you provide, which includes a lot of stuff that need not be included. All you really need is a modified boards.txt and a new bootloader hex file - you should need separate core and firmware directories (and you really don't want them, either!)

yes due to older avrdude i have to add the latest avrdude which is quit large enough in the latest version only the arduino confs are needed to be edited