"Programmer is not responding" Arduino NG/Win32

I ordered a new Arduino NG from Sparkfun and like many others, I am having trouble getting it to work under Windows XP. I have tried the steps from the various posts in the forum, none of which seem to help. I consistently get "Programmer is not responding".

  • Hardware & OS:
  1. Toshiba M200, WinXP, USB 2.0
  2. Fujitsu B2620, WinXP, USB 1.1
  3. Fujitsu P1510D, WinXP, USB 2.0
  • Baud rate:
  1. 9600
  2. 19200
    Made corresponding changes both in Device Manager for the port and in %APPDATA%\Arduino\Preferences.txt. Made sure Arduino was closed when editing the file.
  • Arduino versions:
  1. Arduino 0006
  2. Arduino 0004
  • Pressed reset button...
  1. ... simultaneously with Ctrl-U (Same as clicking the Upload button)
  2. ... 1 second before Ctrl-U
  3. ... 2 seconds before Ctrl-U
  4. ... 1 second after Ctrl-U
  5. ... 2 seconds after Ctrl-U
  • Uninstalled and reinstalled serial port

  • Power options

  1. External power (12V)
  2. USB power
  • Parity:
  1. Even
  2. Odd
  3. None
  • Flow control: none, Data bits: 8, Stop bits: 1

This is the behavior I observe with LED on pin 13 (I suppose 'L' is the same as the LED on pin 13) and ground:
a) Plugged into power:

  • TX & RX blink
  • PWR lights up
  • L and LED blink, then after 9 seconds start blinking at c:a 3 Hz.

b) Press reset button:

  • L and LED blink, then after 9 seconds start blinking at c:a 3 Hz.

c) Press reset button and performing an upload:

  • RX blinks after a little delay, disregarding whether upload was done before or after reset
  • About 3 seconds after RX blinks, the IDE reports "Programmer is not responding."
    ( * L and LED blink, then after 9 seconds start blinking at c:a 3 Hz. )

I really can't think of anything else to try -- except perhaps trying it on a Mac, but that is not an option.
Any suggestions? Does it sound like the board is broken?

Thanks!

Does it sound like the board is broken?

not on Windows, so can't help with the software problem, but from what the manufacturer has said, the rate of broken boards is really really really low-- a fraction of a fraction of a percent. Basicaly it is almost never the board. It's much more likely that it's something to do with the way the software is installed in your computer. Have look throught he forums for info on seiral conflicts, that would be my guess-- that another program is using the serial port. (You've installed the FTDI drivers, right? Just checking :slight_smile: )

Wow, very detailed report.

As Daniel says, check that you don't have any other programs using the serial ports (sometimes these are non-obvious, like zonealarm or other firewall programs). Also, try waiting longer after the Ctrl-U to press the reset button. On some machines it takes a long time to compile your sketch, so the upload won't start until well after you've pressed Ctrl-U.

(Thx for the fast replies! ...and yes, I have the FTDI drivers and all that installed)

I've tried the previously mentioned permutations over again and varied the timings more, but it doesn't seem to help.

However, I managed to get it to recognize the AVR once but it still failed to upload:

Binary sketch size: 4236 bytes (of a 7168 byte maximum)

Atmel AVR ATmega8 is found.
Firmware Version: 1.18
Firmware Version: 1.18
[VP 3] Device is not responding correctly.

Binary sketch size: 4236 bytes (of a 7168 byte maximum)

Programmer is not responding.

I have not been able to reproduce this result.

I look in the preferences.txt file and notice a number of parameters for the serial port:
serial.stopbits=1
serial.databits=8
serial.download_rate=19200
serial.parity=N
serial.port=COM4
serial.debug_rate=9600
serial.burn_rate=115200

My parameters under Device Manager are: 19200 bps, 8 data bits, Parity=None, Stop bits=1, Flow control=None
I assume that debug_rate and burn_rate are for serial communication and bootloader burning, respectively -- thus irrevelevant?

Also, maybe someone can explain what actually happens during those first ~10 seconds after I press and release the reset button?

Also, note that the RX light flashes once a few seconds after Ctrl-U. I assume that it indicates some attempt of communication.

No serial port monitoring software running and I've turned off the firewall just in case. Interestingly, I tried with a different device (the Video Critter, from critterandguitari.com) that uses the FTDI chip. It works just fine with the same driver as the Arduino (the MCU and flash utilities are completely different of course). So, I actually have the FTDI driver and USB serial working on my machines. I suppose this means that the issue seems to be something with the board, the Arduino IDE or the bootloader. Are there any other tests that I can do besides the random timing variations?

Thanks!

It's starting to sound like it may be a problem with the board. The behavior of the on-board LEDs when you reset the board suggests that the bootloader is burned, and the fact that the RX light flashes when you hit upload means that the computer is attempting to communicate with the board. I can't think of many situations in which those two things would be okay, but the upload would still fail. You're not resting the board on a conductive surface (like the anti-static bag in which it came) are you? You've tried powering the board with the USB connection, correct? (I'm more confident in that setup than in the use of an external power supply.)

Guess, I just have bad luck then...

(No, not resting on a conductive surface. Yes, I tried with both powering options.)

So, do I need to go through Sparkfun to get a new board or can I get it directly from Arduino?
I am currently in Europe, so it would be nice if the replacements wouldn't have to travel back and forth across the Atlantic...

i seem to remember a few people reporting that the reseating the Atmega ship in its socket fixed their problem... try removing it, inspecting the socket and reseating it.

Tried removing and reseating the chip, but still no luck.

i think i've run into the same problem.

especially concerning the leds: pin13 flashes up on reset, stays low for 10 seconds an blinks then.
when i am in "initial mode" (13 low), uploading results in TX and RX flashing shortly, in "normal" (13 blinking) mode, only RX flashes.

i've not changed any of the default settings except changing atmega8 to atmega168; running on linux with full privileges; board is new; using power from serial.

is there a "final solution" to the problems described by xibra?

webograph: which sketch are you uploading? What error (if any) do you see in the Arduino environment? Try setting upload.verbose to true in your ~/.arduino/preferences.txt file (while the environment isn't running), then relaunch the environment and try uploading again - this will give more detailed information.

preference set, output is:

Binary sketch size: 1902 bytes (of a 14336 byte maximum)
uisp -v=4 -dpart=atmega168 -dprog=stk500 -dserial=/dev/ttyUSB0 -dspeed=19200 --upload if=/root/sketch_070316a/applet/sketch_070316a.hex 

Transmit: { 0 [30]   [20] }
Programmer is not responding.

the scratch is the standard "blinking led" code with the intervals changed.

edit: i'm using 0008 Alpha from svn

Hmm... when you reset the board and press the upload button, does the RX light flash before the LED (on pin 13) turns back on? Does the TX light flash too? Are you running any other software (firewalls, PDA sync applications, other physical computing tools) that might be using or blocking access to the USB ports? The ATmega168 is firmly in place? The board's not resting on anything conductive?

problem solved, solution unknown (tried it again today, works now).
it was definitely not my timing, although i suspected so for some time.
thanks for your help, sorry i can not give you any solution.
concerning your questions: rx and tx flashed after i pressed "upload"; no other software was running, chip seemed to be in place, no conducting surface.

I got the same thing.

Just pull out your USB, Put it back in, and upload 1 second after it's recognized.
The sketch will upload and after that the rest button will work again.

bug I suppose.

for me, it worked exactly the other way round: after booting, it works until i unplug the arduino and re-connect it. guess it has something to do with the way /dev/ttyUSB0 is set up, but i can't figure out what exactly i have to do to make it work again.
(using gentoo linux with custom kernel)