# ATmega2560 not responding on hand-assembled PCBs

I've assembled some PCBs that I had made, and I'm unable to get the ATmega2560 to respond to programming via the ICSP header. On the third board I'm trying, I have soldered on only the MCU, the ICSP header and a reset pull-up resistor.

Here are the things I've checked:

• No shorted pins
• Supply voltage to all the Vcc pins
• Ground connection to all the GND pins
• MOSI, MISO, SCK and RESET all have continuity from the header to the pins
• The programmer works (tested with an Arduino Mega 2560)
• That ATmega2560s are shipped with the fuse bits set to use the internal oscillator

The DSO shows RESET going low, clock, and MOSI coming in, but no MISO goes out.

What else could I check?

• Is the SPIEN fuse programmed? – Ignacio Vazquez-Abrams Oct 16 '13 at 4:15
• did you already use of the MCU? are you sure that it's intact? can you put a picture of your PCB? is the source oscilator internal or external? – Roh Oct 16 '13 at 5:18
• I hope You have checked RESET and VCC is Proper or not? Check the errata in page 431 has lot of known issues. one is IC will not work under 2.4V. One more thing is CHeck any output signal from IC to confirm IC alive or not? like Port F ("pull-up resistors on pins PF7(TDI), PF5(TMS), and PF4(TCK) will be activated even if a reset occurs.") – user19579 Oct 16 '13 at 9:08
• there can be problems due to bad soldering (shorts with multiple pins), Check the impedance of critical pins like VCC,RESET. check impedance of other IO pins randomly – user19579 Oct 16 '13 at 9:37
• Is the PCB masked? If not, is there a possibility of a short under the chip? Is there voltage between all the ground and vcc pins around the chip when it's powered up? Just checking continuity might not be enough - make sure power is getting to the chip. Also, check for loose pins. It may be that when you test them you're pressing them down onto the pad with the probe, but they aren't actually all soldered down completely. Check for a good solder filet on each pin. – Adam Davis Oct 16 '13 at 15:45

Okay, I figured out the problem. It was simply that avrdude was trying to communicate too quickly for the default clock (8MHz internal oscillator divided down to 1MHz). Adding the -B 3 option to avrdude to set the bitclock fixed the problem (insofar as it responds with the right device ID).