help bootloading atmega328p-au

This is maddening. I’ve tried 2 virgin chips now with the same results. What am I missing? 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’m using an Arduino UNO as the ISP. I’ve checked connections a dozen times all with the same result. I’ve attached the schematic. If anyone can help, please do. I’m pretty much at my wits end with this SMD crap.

Your schematic is missing labels - can’t tell if J2 is wired to SCK, MOSI, MISO, Reset, +5, Gnd correctly.

For the sake of argument, assume they are. I'll get them labeled in the mean time.

You've buzzed between the IO pins, nothing is shorted out?

Try Nick Gammon's bootload programmer instead. http://www.gammon.com.au/forum/?id=11635

Why don’t you try burning the bootloader directly with avr dude commands on the console?

Sometimes the Arduino IDE just doesn’t want to burn (happened to me more than once). Then I used avr dude commands on the console (cmd.exe for windows users) (you must install avr dude first) and then I could burn without trouble.

Edit: This is the command I use
avrdude -c usbtiny -p m328p -U flash:w:bootloader.hex

In your case you should change “usbtiny” for “arduino” because arduino is the programmer. Instead of “bootloader.hex” just write the bootloader you want to burn (look inside the Arduino folder instalation).

Yeah I realize the schematic isn't clear. The LCD is removed for programming via ICSP header. The schematic is correct. All nets are going to their respective pins (MISO, MOSI, SCK, etc).

I did figure it out tho. The problem is with the reset. I shared the reset pullup and inline cap. Turns out this doesn't work with the ICSP header using an Arduino as ISP. To test this theory I soldered a piece of wire to the trace between the MCU reset pin and the pullup resistor effectively bypassing the cap. I removed the reset wire from the header plug and soldered it to the wire I put on the trace. Bing-bam-boom it worked the first time. So there must be a difference in the way the FTDI DTR handles reset as compared to ICSP. Lesson learned.

This is a custom board that I etched. It still a prototype and certainly needs some refinement.

planecrazy29: To test this theory I soldered a piece of wire to the trace between the MCU reset pin and the pullup resistor effectively bypassing the cap.

Oh I didn't notice that C5 cap in your schematic, the same problem happened to me once. Removing the auto-reset cap did the trick for uploading with ICSP. Now I use a mini jumper (as in the arduino severino) to enable-disable auto-reset (to disconect the cap).

That's where labels come in - if you had labelled the left side of cap C5 DTR and the right side Reset, you would have been good.

It makes a difference for Serial programming, where cap helps make a reset pulse, and ICSP programming, where the programmer holds reset pin low to access the memory more or less directly via SCK/MOSI/MISO.

CrossRoads: It makes a difference for Serial programming, where cap helps make a reset pulse, and ICSP programming, where the programmer holds reset pin low to access the memory more or less directly via SCK/MOSI/MISO.

This is what I didn't know. Labels wouldn't have helped me. I still would have run the ICSP reset through the cap :D

Thanks for the clarification tho. That helps me.

I still would have run the ICSP reset through the cap

Yes, but I could have pointed out sooner that the wiring was incorrect then.