ATMEGA328P-AU Board Bootloader Fail

Hi all,
I know there have been a few threads about burning a bootloader to the ATMEGA328P-AU SMD chip, but I have read a few, and don’t know where I am going wrong.
I am using the Arduino as ISP and have successfully burned to DIL chips (-PU) using a 16MHz resonator.
I am now trying to burn to the SMD version (-AU) in situ using the internal oscillator and am constantly getting the error of

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

When I use the verbose output, it seems the signature being read is 0x000000.
I have engaged the low speed setting in the Arduino code, but no joy.
I have even tried holding a lead from pin 9 (the 8MHz clock generated by the Arduino code) to the XTAL1 pin as I read that if the fuses are set to use an external clock, you can’t burn a new bootloader without one.
Any advice greatly received.
I can post a schematic and .brd file for the PCB I made if that would help!

I can post a schematic and .brd file for the PCB I made if that would help!

Please do - use File:Export image and Attach those files, not everyone here can open Eagle files. I burn bootloaders to SMD chips all the time - did 20 2 weekends ago, with AVR ISP MKii and a SMD adapter http://www.hobbyking.com/hobbyking/store/__64417__Atmel_Atmega_Socket_Firmware_Flashing_Tool_AR_Warehouse_.html?strSearch=atmega and a 10-pin to 6-pin adapter (the other 4 pins are just GND and are not needed).

Turns out I was not making good contact with the ICSP header because the wires going into the 6-pin IDC connector were getting marginal, only making contact if bent just right. With the 10-pin to 6-pin adapter for the SMD adapter, things were making good contact. Discovered the marginal connection during the 19th board, cutting the wire back a little and crimping on a new IDC connector solved the mystery for me.

Schematic and Board Layout attached

Board Layout.png

It looks to me like the combination of the resistors you have in the programming signals, and the LED/resistors you have on the programming pins, are going to result in logic levels that are not valid during programming...

The resistors in the programming signals are 0 ohm and are acting as jumpers. Would the LEDs on the pins cause issues? I would have thought that given they are driven by outputs from the Arduino and the ESR of the connection would be very small, they should be still giving a logical high or low, or am I missing something?

Programmer is likely having trouble driving SCK & MOSI with the LEDs there, and chip having trouble driving MISO. Can you leave those jumpers off until after bootloading? LEDs need more than 0 ohm, that will blow the IO as they overcurrent trying to drive the LEDs.

AREF should not have need connected to +5, it only needs a 0.1uF cap to Gnd It connects to +5 internally when EXTERNAL AREF is selected.

If the programming signal resistors are 0 ohms, I guess it should be OK. 100ohms and an LED is a bit "strong" to be driven by a AVR pin, though, but it's probably something else. (the PCB looks like there are lots of things shorted together that shouldn't be. I hope that's just an image export issue?)

LEDs need more than 0 ohm, that will blow the IO as they overcurrent trying to drive the LEDs.

Sorry, misunderstanding. The 0 Ohm resistors are on the signal lines only. The protective resistors on the LEDs are 22 ohm (calculated using the voltage drop across the LEDs and their current limit). I will try again with the LEDs disconnected, but fear this may make the whole process too fiddly with multiple trips to the SMD oven. Is it possible to burn the bootloader onto the chip in a ZIF socket before soldering to the board, or might the heat of an SMD reflow oven in some way erase that data (sorry for ignorance on this one!)?

The protective resistors on the LEDs are 22 ohm

that's a very low-value resistor ((5-2.2)/22 ~= 120mA !) The Arduino pins have a current limit as well (~20mA), and typical LED current limiting resistor values are 220 ohms or higher.

The system is running on 3.3V and the LEDs I'm using have a threshold voltage of 3V typical and so I am limiting them to 20mA. Sorry, should have clarified the voltage issue (although of course when programming from the 5V arduino system, you are right they will draw more. Maybe this is the problem, hadn't thought about that!)

I'm really tempted to give up on the programming in situ idea. Is there a reason why I can't solder them on after programming the bootloader?

You can bootload them first and then install them. Some things to think about: Ideally your PCB design would have a provision for programming the chips, because you may need to reprogram or re-bootload the chips somewhere down the road anyway. This provision could be in the form of jumpers, and when you remove the jumpers it not only disconnects the traces to the resistors and LEDs, but also provides a convenient place to plug in the programmer. There are voltage-selectable Nanos and Unos that you can get at low cost, so you can make your own 3.3V programmer. Or you can take a cheap 5V Nano and modify it with a 3.0 V regulator for an even more custom/dedicated programmer. For a makeshift solution that should work with your current PCB design, if you solder the processor before the resistors you would have an opportunity at that point to access the processor for programming without any potential problems. You do need to at least cut that trace that puts VCC on AREF.