I have the shield on my Arduino Duemilanove, but without the atmega328 in the ZIF socket. If I have "override autoreset" set to "No Way", it uploads fine. Then i place the atmega328 in the ZIF socket, making sure it's correctly oriented. When I try to Burn Bootloader w/ Arduino as ISP, I get the "resp=0x15" error, meaning I need to switch "override autoreset" to "Yes Please". So I do. Then, if I try to upload the sketch again, I get this error:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x1c

So I put "override autoreset" back on "No Way", and successfully upload the sketch, then put the atmega328 in the ZIF socket. Switch "override autoreset" back to "Yes Please", and when I try to burn the bootloader, I get this error:

avrdude: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

The Pulse LED is pulsing normally. When I upload the sketch with "override autoreset" off, the Prog, Error, and Pulse LEDs blink briefly, then just the Pulse LED pulses. What is the problem?

I have the shield on my Arduino Duemilanove, but without the atmega328 in the ZIF socket. If I have "override autoreset" set to "No Way", it uploads fine.

I can probably help you, but I need you to be clear and specific about what's going on. "It uploads fine" doesn't mean anything, since you haven't said *what* you're trying to upload to what, using what protocol, and what is hooked up where.

- Are you uploading the "ArduinoISP" sketch to the Duemilanove, or are you uploading a program to a chip hooked up to the ISP shield through one of the ribbon cables? If the latter, what command are you using in the Arduino environment-- are you uploading a sketch or burning the bootloader?

On the Duemilanove, the "override autoreset" must be set to "no way" to upload the ArduinoISP sketch.

When I try to Burn Bootloader w/ Arduino as ISP, I get the "resp=0x15" error, meaning I need to switch "override autoreset" to "Yes Please". So I do. Then, if I try to upload the sketch again, I get this error:

On the Duemilanove, the override autoreset must be turned on ("yes please" in order to use the burn bootloader w/ Arduino as ISP option.

So I put "override autoreset" back on "No Way", and successfully upload the sketch, then put the atmega328 in the ZIF socket. Switch "override autoreset" back to "Yes Please", and when I try to burn the bootloader, I get this error:

What sketch are you uploading this time? And, how (and why) are you doing that?

I'm following the instructions here, under the "...To program the Arduino Bootloader onto an ATmega168/ATmega328":

By "uploading", I mean uploading the sketch at File>Examples>ArduinoISP to my Arduino Duemilanove, via the Arduino IDE. I'm not using any hardware, besides my laptop, the Arduino, and the shield. Yes, I have the override autoreset set to "No Way", and the sketch uploads fine. Then I put an atmega328 into the ZIF socket on the shield, and lock it in place. Finally, as per the instructions in the link above, I go to Tools> Burn Bootloader> w/ Arduino as ISP. However, the Arduino IDE returns this error:

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

In the instructions, it says that this error means override autoreset needs to be set to "Yes Please". So I switch it, and retry burning the bootloader as above, and I get this error:

avrdude: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

I know it says "... or use -F to override this check." But where do I actually enter "-F"? If I try to upload the sketch with override autoreset on "Yes Please", I get this error:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

On this error, it also gives me a link to the Arduino website's Troubleshooting area on uploading, which didn't offer any help. Thank you for trying to help, and I'm trying to be as specific as possible.

By "uploading", I mean uploading the sketch at File>Examples>ArduinoISP to my Arduino Duemilanove, via the Arduino IDE. I'm not using any hardware, besides my laptop, the Arduino, and the shield. Yes, I have the override autoreset set to "No Way", and the sketch uploads fine. Then I put an atmega328 into the ZIF socket on the shield, and lock it in place. Finally, as per the instructions in the link above, I go to Tools> Burn Bootloader> w/ Arduino as ISP. However, the Arduino IDE returns this error:

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

In the instructions, it says that this error means override autoreset needs to be set to "Yes Please".

That all sounds correct so far.

So I switch it, and retry burning the bootloader as above, and I get this error:

avrdude: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

I know it says "... or use -F to override this check." But where do I actually enter "-F"?

You should not override that check-- if it's throwing that error, then there's very likely actually something wrong (that "double check connections" part), that needs to get fixed.

I'd start by checking-- very carefully --for possible bad solder joints, missing components, or other things that could interfere with operation. Compare carefully with our photos for component placement and orientation, and then examine *every* solder joint completely for possible dry or cracked areas or accidental connections between neighboring pins.

Finally, leave the whole unit assembled (Duemilanove + shield w/ locked-in '328), and disconnect the USB port from your computer and plug it back in. Sometimes the act of inserting a chip can cause an electronic glitch that will cause the computer to no longer recognize USB items until they are unplugged.

Triple checked all solder joints. Even refreshed some that looked "iffy". I have all of the parts correctly soldered, and in the right places. Except for the 6-pin ISP header. I'm not using it, and none of the pins connect, so it shouldn't really make a difference if it's there or not, should it?

Okay, I'll admit to being a bit stumped here.

Here's what I can tell you:
- The "not in sync" error is a blanket error, covering almost any kind of "it isn't actually connected like it's supposed to be" situation.
- There is very little to go wrong on the ISP shield. (Indeed, there is very little at all on the ISP shield.)

If you have access to a multimeter*, I'd suggest checking neighboring pins on the ISP shield (both at the edge connectors and ZIF socket) for accidental connections, and further checking (versus the circuit diagram) to make sure that there's continuity between the relevant pins of the ZIF socket and the shield sockets.

There are some other things that could cause programming not to work. One of them is a "bad" target AVR-- either damaged, or with the fuses in an unusual configuration. Another is if the 16 MHz oscillator on the shield isn't working, for example if the wrong capacitors were installed next to it. So, check those caps, and try another AVR if you have one.

If you can't get it to work, please contact our store directly, to discuss some "offline" solutions.


*You really just need to check continuity here. If you don't have a multimeter, you can make a continuity checker with some wire, an LED, a battery, and a resistor. Be sure and check continuity with the shield disconnected from the Arduino.

Thanks for your help. All connections are connecting where they're supposed to, and not where they're not. The capacitors are correct. I tried replacing the oscillator with another 16MHz I had on hand, and still nothing, so I'm thinking that if there's a fixable problem, it's most likely the AVR. I'll Try another one, and post a reply on here with the results for anyone else in my position.

The new 328 came in, but I'm sorry to say it didn't help. When following the same procedure as above, I now get a new error:

avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Double check chip, or use -F to override this check.

Since I'm not really getting anywhere, just out of curiosity, where do I actually enter "-F"

Since I'm not really getting anywhere, just out of curiosity, where do I actually enter "-F"

As part of the avrdude command. BUT, this is a symptom of another problem, not the cause. Skipping that check just means that it's going to foul up later, where it could potentially do more harm.

However, if you are getting a new error, that *is* a significant change, and may mean that you are on the right track.

Quote by: metrogdor22

The new 328 came in, but I'm sorry to say it didn't help. When following the same procedure as above, I now get a new error:

avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Double check chip, or use -F to override this check.

Since I'm not really getting anywhere, just out of curiosity, where do I actually enter "-F"

This is cut from an e-bay listing from which I nearly bought some AT328s..

ARDUINO USERS PLEASE NOTE:
The AVR ATMega328p sits at the heart of the enormously successful and popular Arduino development platform (see the book “Getting Started with Arduino” available in most booksellers and tech shops). However, Arduino Users PLEASE NOTE: What we are selling here is a completely blank AVR Chip, it has no bootloader installed. You can only use this chip in an Arduino board after programming it with a bootloader. You will need an AVR ISP programmer, or a 3rd party AVR programmer such as the Pololu programmer to do this. You may also find the breakout board from Sparkfun useful. You’ll find information about bootloaders and outline instructions on how to burn one into a blank AVR chip on the Arduino website: See “Burning the bootloader” here.

The version of the chip we offer here is the -pu version of the chip. To use it with Arduino, you have to “fool” the C compiler and the AVR programmer software (AVRDude) into thinking it is a ATmega328p because this chip returns a slightly different signature code (see below) which makes the AVR-C compiler think it doesn’t know the chip.

Here’s one method to make this version of the AVR chip work with Arduino on Windows (using Arduino rev 22, and previous versions).

1) If necessary, modify the “boards.txt” AND “programmers.txt” files in your Arduino installation to make it aware of your ISP programming device. Your programmer vendor should have provided details of how to do this for your programmer board, for an example, see the Pololo website on this subject HERE.

2) Now, when you use your programming environment you should be able to select the board you added in step (1).

3) Use your programming environment as usual, however hold down the SHIFT key at the same time as you hit the “upload” button. This will put Arduino into verbose bode, and it will show you the commands it issues to invoke the Avrdude program. Avrdude is the program which *really* uploads the binary version of your program into your AVR chip. With the AtMega328-PU the upload initiated from Arduino will usually fail, because the signature bytes returned by the chip don’t match the signature from a pico-power version of the chip. (the –pu version of the chip returns signature 1E 95 14 instead of 1E 95 0F which Avrdude is expecting for an Atmega328p).

4) In the Arduino window, scroll all the way up the log text (which is in red). At the top, you will find the complete avrdude command that Arduino used to burn the compiled version of your code into the AVR chip. Select all of this command and copy it into your paste buffer (using CTRL/C once selected)

5) Startup a command window. Paste the avrdude command line into the window by clicking the top left button of the command window, then edit->paste. BEFORE pressing ENTER add the text “ –F “ just after the avrdude command word. This will make the program skip the signature check, and it will continue the programming of the device successfully.

There are other ways to make the Arduino software set program the ATMega328-PU (for example upgrading the compiler) but the method above is useful because it does not involve making your Arduino installation non-standard. You can see yet another method HERE. It is possible that future updates of the Arduino software set will make this unnecessary, but as of version 22, it is required.

Do you by any chance have a '328-PU (or other variant '328) causing this error? The key issue is "the chip returns signature 1E 95 14 instead of 1E 95 0F which Avrdude is expecting".

The above would appear to be the fix if that's the issue. I haven't tried it myself - It's taken from here: http://www.ebay.co.uk/itm/170709892516

Personally, I have had the error you had originally. That in fact is the error you get if you have no chip at all in the target slot. I was not using the shield but had my target chip on a breadboard and it turned out it had no power! I wonder whether you might have had a bent pin or something on the original processor so it was simply not responding at all (or maybe it's just fried).

In case anyone else has this problem (which by odd coincidence I had tonight), this is what I think the problem was and an easy solution:

If you have a 328-PU in place of the normal 328P it has a different signature byte. Functionally it's the same chip but AVRdude won't recognise it.

Easiest fix is to find your avrdude.conf file and in the entry under ATmega328, edit the line:

signature = 0x1e 0x95 0x0F;

to read:

signature = 0x1e 0x95 0x14;

The former is the sig for a 328P the latter for a 328.

Works like a charm after that.

Obviously you might want to edit it back again after.

Ugi

I've run into this before.

I was about to comment that everything is the same, except operating voltages, (the P is pico-power)
when I went to check the datasheet, though, It looks like they both go down to 1.8 V (I could have sworn that the Non-p had a higher bottom number).

Now the actual power consumption/sleep modes are different, but at least for current chips they are both spec-ed to operate down to 1.8v

I wonder if they are actually the same chip (now) but with different signatures. It would be interesting to check their pico-power characteristics...

I have to say that I wasn't too worried - this project is running off an ATX power supply, so I have 30 Amps to play with!

Interesting nonetheless and I dare say at some point I will want to run one off a lithium coin-cell or something where every microamp will count. Does sound as if they may have converged and maintain the different signature for comparability's sake (or indeed incompatibility in my case).

I could find surprisingly little on the Arduino forum addressing this issue. I find it hard to believe that everyone there buys kits or pre-made boards that come with 328Ps or pre-bootloaded chips. Maybe I'm just rubbish at searching!