Go Down

Topic: Another ATMEGA328-PU Bootloader Problem (Read 944 times) previous topic - next topic


Hi all, let me preface this by saying that I have done the research about bootloading the ATMEGA328-PU vs the ATMEGA32P-PU. I am using an Arduino Duemilanove with the arduinoISP program loaded on it to program my blank chip. The reset line on the Duemilanove's reset line has been tied high with 3 330 ohm resistors in parallel giving 110 ohms of resistance between the reset pin and 5v supply. I have gone over and over the wiring to check that the MISO, MOSI, SCK, and Reset lines are going to the respective pins on the Duemilanove. I have also tried changing the lock bit/ signature from 0x0f to 0x14 as suggested in other posts about this particular issue. I have even tried using both the mac and windows versions of the Arduino 1.0.4 to see if it was an OS problem. Despite all of this I still get an avrdude error about the device code not being recognized. What am I doing wrong here? Do I perhaps need a 16mhz crystal on the crystal pins for it to work correctly? I tried burning it with the Duemilanove bootloader as well as the 8mhz @ 3v arduino pro bootloader with the same results so I get the feeling that it is not the crystal. Any help would be much appreciated, I get the feeling that a new set of eyes will reveal some simple problem that I have overlooked. I will post a picture of the breadboard as it is currently hooked up shortly.

Nick Gammon

The reset pull-up is supposed to be 10K not 100 ohms. Try that first.


The reset pull-up is supposed to be 10K not 100 ohms. Try that first.

I think the OP is defeating the auto-reset on the Duemilanove board with the low ohm resistor to temporarily disable the auto-reset on the 'programmer' board running the arduinoISP sketch. That's per most instructions, no?

Actually I've used my Duemilanove maybe a dozen times as the arduinoISP programmer and never once had to defeat the auto-reset function, but I understand it's a timing thing and is not always effected by the auto-reset process.


Nick Gammon

The picture would be good. The chips ship with the divide-by-8 bit set which won't be helping, probably.

I have stuff about setting up minimal boards: http://www.gammon.com.au/forum/?id=11637


Here is the photo. I am beginning to think that the problem lies in avrdude not recognizing the chip as the error is an avrdude error, not an Arduino error. Thanks again for your help!

Nick Gammon

Can you copy and paste the error message please?


Sorry, I should have done that in the first place.

Error message from Mac, burning the Duemilianove Bootloader: "avrdude: stk500_getsync(): not in sync: resp=0x15"
Error message from Mac, burning the ProMini 8mhz @ 3.3v Bootloader: "avrdude: stk500_getsync(): not in sync: resp=0x15"

The error message in windows says something along the lines of "Yikes the device ID wasn't recognized. Press -f to override." I don't have access to the windows computer at the moment so I couldn't get it verbatim but that is the essence of it. What I also found is that when I add a board to the boards file in Mac, it doesn't show up in the list so I am not sure if changing the lock bit in the boards file is actually doing anything.


The non-P 328 has a different Signature to the P version.

This isn't present by default in boards.txt or averdude.conf.

You need to modify both files to add support for the non-P 328, in order to burn a bootloader and set fuses. Once you have a bootloader installed the you have to revert back to the standard 328P board in IDE to upload sketches over serial.

I believe that Nicks programmer sketch might support the non-P and save you needing to make the modifications. I haven't tried it personally but I think I saw in the code that it looked like it supported non-P 328.

I've successfully burnt bootloaders to non-P using Arduino ISP with the mods to boards.txt and averdude.conf

Go Up