avrdude: stk500_recv(): programmer is not responding

Sorry if this is a trivial fix but I could not find an answer.

I’m getting the following error:

avrdude: stk500_recv(): programmer is not responding

…when trying to upload a sketch to my Nano V3.0 for Arduino board. http://dx.com/p/arduino-nano-v3-0-81877
After I hit upload the RX led blinks 3 times and then nothing. I’m not sure where to go from here. I’ve installed the FTDI Drivers found here: http://www.ftdichip.com/Drivers/VCP.htm
This is the 2nd board I’ve tried with the same problem, so I’m inclined not to think it’s a hardware issue.
Any help is appreciated.
Thanks

-Tony

Does the "L" led blink as well? If it blinks when you plug in the nano, but not when you click upload, perhaps the auto-reset is broken and you could get by with the manual reset method. If it never blinks, perhaps the AVR does not have a bootloader programmed; that has happened with some of the clones. If it blinks both of those times, but doesn't upload at all, it could be running a different bootloader than you expect, and you might have better luck claiming that it is an "Uno" rather than a Nano.

The L led never blinks. I've tried burning the bootloader as a Uno and a Nano 328, both fail to burn.

Also when I press the reset button nothing happens. None of the lights flash. :blush:

The L led never blinks.

That SOUNDS like a missing bootloader.

I've tried burning the bootloader as a Uno and a Nano 328, both fail to burn.

"Burn Bootloader" requires some sort of programmer hardware; you can't do it with just the USB connection to the Nano. Do you have a programmer (or a working arduino board)?

Yes I do have a Uno board and another Nano clone that works just fine.

EDIT: K I took your advice and stumbled across this: http://sysexit.wordpress.com/2013/02/07/burning-a-bootloader-to-an-arduino-nano-using-another-arduino/

That describes how to go about fixing the problem perfectly. But it didn't work for me. I checked all the connections, everything seems fine. I can upload sketches just fine through ISP. But I get the following error when trying to burn the bootloader.

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

Then I checked in the comments and saw this post.

Thanks, this helped me very far, but I got a connection error when trying to burn the bootimage. Checked every connection and could not find any problems. Uploading sketches through the ISP worked fine. To fix the problem I used this sketch: https://github.com/adafruit/ArduinoISP/blob/master/ArduinoISP.ino

Had to use the “slow speed chip erase and fuse burning” as described in the large comment on top. After erasing, fuse burning and re-uploading the ISP sketch without slow mode, burning the bootimage worked from the Arduino IDE

I'm not sure how to proceed using the "slow speed chip erase and fuse burning".

// SLOW SPEED CHIP ERASE AND FUSE BURNING
//
// Enable LOW_SPEED to allow you to erase chips that would fail otherwise,
// for being running with a clock too slow for the programmer.
//
// This allowed me to recover several ATMega328 that had no boot loader and the
// first instruction was to set the clock to the slowest speed. Usually this
// kind of recovery requires high voltage programming, but this trick will do
// just fine.
//
// How to proceed:
// 1. Enable LOW_SPEED, and load it to the programmer.
// 2. Erase and burn the fuses on the target uC. Example for ATMega328:
//   arduino-1.0.1/hardware/tools/avrdude -Carduino-1.0.1/hardware/tools/avrdude.conf -patmega328p -cstk500v1 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900cf1Q-if00-port0 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xF7:m
// 3. Comment LOW_SPEED and load it back to the programmer.
// 4. Program the target uC as usual. Example:
//  arduino-1.0.1/hardware/tools/avrdude -Carduino-1.0.1/hardware/tools/avrdude.conf -patmega328p -cstk500v1 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900cf1Q-if00-port0 -b19200 -Uflash:w:firmware.hex:i 
//
// Note 1: EXTRA_SPI_DELAY was added to let you slow down SPI even more. You can
// play with the value if it does not work with the default.
// Note 2: LOW_SPEED will alow you only to erase the chip and burn the fuses! It
// will fail if you try to program the target uC this way!

//#define LOW_SPEED
#ifdef LOW_SPEED
#define EXTRA_SPI_DELAY 125
#else
#define EXTRA_SPI_DELAY 0
#endif

Step 1 means to remove the "//" before the "#define LOW_SPEED", correct? I'm not sure what step 2 is all about.

Very confusing...

I am having the same problem with my Nano V3.0 but on Lubuntu 12.04 LTS

I have 2 nanos i purchased on Amazon that worked out of the box, but when I came back after a time I was dealing with this error. After an Arduino reinstall it seemed to fix it, but I don't understand why and now I am having the same problem

Tonight, I was receiving 2 different errors:

1) avrdude: stk500_recv(): programmer not responding 2) avrdude: stk500_getsync(): not in sync: resp 0x00

after Arduino reinstall removal/reinstall via Synaptic, the second board is fine and driving a servo, but the first is still showing the _recv error listed as the thread topic. I have tried uploading as Arduino Uno and Nano, but receiving the same error.

The L led is blinking, but the Loop-Back test would not print back my text. Since the L led is blinking, I'm assuming I don't need to reburn the bootloader, but that would be my next guess unless anyone else has a suggestion.

The instructions for reinstalling the FTDI driver in Linux is rather complicated, and I'm hoping there is an easier fix since one of the two Nanos is now functional.

It seems that this is a relatively new problem specifically for Nano that is not limited to Mac OS, at least according to my searches.