Programmer is not responding

(This were some single posts before, I put them together for better understanding)

Hi @ all!
Today I got my arduino-ng board and was quite happy to have it in my hands...
But after some hours with it, I have to admit that it feels like it won't work Sad

It tried the Arduino-7 Software under both Windows and Linux, with different delays between pressing reset and trying to write to the device. Tried usb vs. external power. I got a ATmega168 with bootloader too, so I re-seated about 10 times... same results:
"Programmer is not responding."
I even tried AVR-Studio for Windows... The only difference is, that AVR-Studio seems to retry the connection attempt resulting in longer RX activity.
Tried another USB-cable and another computer...

But I have never ever seen any TX activity (except after connecting the USB-plug)!!

The ATmega8 does one L-led flash after reset, then some seconds nothing and then flashing about 3Hz.
The ATmega168 does 3 flashes, then some time noting, then 3 flashes and so on.


Hmm... with the ATmega8, does the RX light flash before the L LED starts blinking at 3 HZ?
If so, you've got the timing right, as the bootloader is listening for uploads when the LED is off.
Yup.

Can you try setting the upload.verbose flag (in your preferences file) to true and post the output you get?
Sure, but I'd like to do:

./uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/ttyUSB0 -dspeed=19200
Transmit: { 0 [30]   [20] }
Programmer is not responding.

I get the same output with other baudrates (9600, 2400, 1200) and under Windows and with the atmega168 (of course I set -dpart=atmega168).

With avrdude I get:

./avrdude -F -p atmega8 -P /dev/ttyUSB0 -c stk500 -b 19200 -vvvv
         avrdude: Version 5.3.1, compiled on Jan 13 2007 at 22:28:39
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "/usr/local/etc/avrdude.conf"
         User configuration file is "/home/jakob/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port            : /dev/ttyUSB0
         Using Programmer      : stk500
         Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: Q [51]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

As I said, I tried AVR-Studio too. It seems it retries to (re-)send the init sequence of 0x30 0x20 a couple of times, but does get no answer either.
I can even manually send some bytes to it, no response.
(The easiest way is something like echo "0" > /dev/ttyUSB0)

Any comments? Due to the fact more people have the same problem with the arduino-ng, could it possibly be a hardware or design issue?

BTW: I got my arduino-ng from Smart Projects.

Hi there,

no solution - I'm just having the exact same problem with my newly received Arduino NG (by PCB Europe).
Read all the previous posts concerning this Problem, tried pretty much every proposed solution/ workaround:

  • All Firewalls/ Sync-Software disabled

  • Tried different Baud rates

  • Checked USB serial port driver (works fine)

  • Tried it on different Machines (though both XP with SP2)

  • Tried it with different Arduino versions

  • Tried different "timing"-Variations (press Reset first, then wait x seconds then upload etc.)

  • Power LED lights up

  • RX/TX light up very briefly when connecting Arduino NG to USB

  • L LED starts flashing/blinking

  • Hitting reset

  • Hitting "Upload to I/O Board"

  • RX flashes very briefly

  • and here we go:

Still I am always getting that same:

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

E:\Arduino\arduino-0007\tools/avr/bin/uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/com4 -dspeed=19200 --upload if=E:\Arduino\arduino-0007\examples\led_blink\applet\led_blink.hex

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

This is getting slightly frustrating :wink:
Anyone any ideas what's going wrong?

Thx,
Moe

Hmm. Maybe the Italian post office has decided they don't like Arduino.

Moe, when you press the reset button, the L LED should flicker briefly, then shut off. It will remain off for about 6-8 seconds; this is the period during which the bootloader on the ATmega8 is waiting for a new sketch to be uploaded from the computer. When you're trying to upload a sketch, did you time it so that the RX LED flashes during this period?

Afterwards, the L LED may begin blinking at ~2 HZ or so; this is a test program that was uploaded to the board.

Hmm. Maybe the Italian post office has decided they don't like Arduino.
So what am I supposed to do now?

I'd try once more in Linux and Windows. If it doesn't work, contact PCB-Europe to ask for a replacement.

Thanks for your suggestions, mellis...

However I'm pretty confident I got the timing right.
Started my Computer today, hooked up arduino, tried uploading the
led_blink - sketch.
Produced some long error message concerning Java (stupid me didn't
save it). All I got from then on is the following:
(now during the uploading process RX AND TX flash briefly)

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

E:\Arduino\arduino-0007\tools/avr/bin/uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/com3 -dspeed=19200 --upload if=E:\Arduino\arduino-0007\examples\led_blink\applet\led_blink.hex

Transmit: { 0 [30] [20] }
Receive: { . [00] }
Receive: { . [00] }
[VP 1] Device is not responding correctly.

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

E:\Arduino\arduino-0007\tools/avr/bin/uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/com3 -dspeed=19200 --upload if=E:\Arduino\arduino-0007\examples\led_blink\applet\led_blink.hex

Transmit: { 0 [30] [20] }
Receive: { . [00] }
Receive: { ` [60] }
[VP 1] Device is not responding correctly.

I still can't imagine that it's a problem with the board - i think it's too early for that :wink:

Any new suggestions?

thanks,
Moe

Actually, it sounds like it is a problem with the board, since the board seems to be sending back the wrong data (and not always the same wrong data either). You should make sure the ATmega8 is firmly in its socket. Also, check that there's nothing conductive underneath the board. Otherwise, maybe the board was damaged in shipping. Try a few more times and see what outputs you get.

Everything back to the good old plain "Programmer not responding".
Tried reseating the AtMega five times without any success, board is not resting on any conductive surface (actually tried different ones - paper, PVC, plastics etc.)

Think i'll get in contact with PCB-Europe and hope for a replacement...

Thanks again for your Help! :wink:

Moe

fyi you should only have to reseat the Atmega chip once, if at all. The idea is to make sure all its pins are contacting, which generally only takes one try. 98% of the time this is not going to help, it's only for the rare cases where the chip and socket are not aligned.

I got my replacement arduino-ng today: It works like a charm!

With the working borad I programmed the serial_hello_world example from Arduino-serial: C code to talk to Arduino – todbot blog onto a atmega8 and put it in the defective board. I get no TX activity at all...
If I can provide any help with locating the error, just tell me!

My replacement Arduino just arrived via UPS - tested it and... it works - finally :wink:

Thanks again for providing help!
yours
Moe

Unfortunately, the lesson of this thread is: if your "Programmer is not responding", you may simply have bad hardware. I just spent several frustrating hours with three Arduino NG boards that I purchased from some desk at Ars Electronica; after I checked all of the obvious settings (correct microcontroller, correct baud rate, checked the bootloader, bla bla) and tried all of the reset button voodoo (one second before, two seconds after, bla bla), I was still getting this error and I thought I was going crazy. The only solution was to roll back to some very crusty Arduino boards (non-NG) that I had lying around. So watch out, and make sure you get a receipt with your purchases. Not only are there bad specimens, but it seems there might even be bad batches.

hey

Massimo will maybe pipe in here, but from experience with hundreds of students using the board, and what I have heard here in the forum, the rate of bad hardware is really miniscule...

What version of the board is it that you bought at Ars? If you have one of 'crusty' board working, you can swap the chip with the NG board and try that to verify if indeed there is a hardware problem.

D

:-[ Well, after I tried everything in the troubleshooting guide, I learned that it was "human error" after all. It seems that I simply had not tried the right combination of voodoo for downloading the program to the board. In my case, I did actually experience some behaviour that I had not seen described before:

I had to press the Reset Button AFTER I pressed "Upload to I/O Board". And when I say AFTER, I mean 4 to 5 seconds after. Seriously. Of course, this is the opposite advice from the feedback returned by the Arduino IDE....

It also turns out that (in my case anyway) there is a very narrow window of time where the Uploader will work. If I press the button too early, "Programmer is not Responding". If I press it too late, "Programmer is not responding". I have less than a second's time to get it right.

So, I hereby apologize to Massimo and the Crew for impugning the hardware -- typical newbie nonsense, I'm sorry. But I have to say, it would be great if there were a "Ready to receive program" indicator on the Arduino board, so that I wouldn't have to guess when to jump into the void.

Regards,
Golan

The problem's with the Arduino software, not the board... That is, there's already a ready to receive signal - an LED on pin 13 flashes three times when the bootloader starts, after which you have 5-6 seconds for the upload to begin. For simplicity, however, the Arduino environment recompiles your code every time you upload (I want to do something about this, but it's not been the highest priority), which on some machines seems to be very slow for reasons I don't really understand. Thus, by the time the upload begins, the bootloader has already timed out.

The suggestion of pressing the reset button after the hitting upload is mentioned on the troubleshooting page http://www.arduino.cc/en/Guide/Troubleshooting, but it's certainly easy to miss. I'll take a look at improving the error message in the environment.

Thanks for the help! I'm glad I'm not crazy.

It might be a reasonable option in the IDE to turn off the compilation-before-upload.

Indeed, I did see that the troubleshooting guide mentioned the possibility of a reverse order (i.e. upload, then reset). What surprised me is that it was 4 to 5 seconds between one and the other, which seems like a long time. When I enrolled in a workshop last year on a different computer, the order was normal and the delay was only a second -- hence my surprise.

I'm on a reasonably new laptop (Dell, Intel Core Duo T7200 @2Ghz). So I don't know if CPU accounts for the extra delay in compiling. Anyway, I've gotten used to it now.

Thanks again,
Golan

Hello,

In fact I have had the same problem. But I have solved it pressing the reset button (in a NG board, also in a mini+usb boards) 4 seconds after the starting of the uploading process.

¿Is there any way to turn off the compilation-before-upload?

Thanks

Not yet. I'd like to make the software smart enough not to recompile a sketch if it hasn't changed, but it opens up a whole lot of complications. Another idea is to have the IDE keep pinging the bootloader while the compilation happens so that the bootloader doesn't time out. This is probably easier to do, though not as nice (since the uploads will still be pretty slow).

BTW, what operating system are you using?

Not yet. I'd like to make the software smart enough not to recompile a sketch if it hasn't changed, but it opens up a whole lot of complications. Another idea is to have the IDE keep pinging the bootloader while the compilation happens so that the bootloader doesn't time out. This is probably easier to do, though not as nice (since the uploads will still be pretty slow).

BTW, what operating system are you using?

I'm using Windows XP. In my case, I believe that the delay is produced for the anti-virus software or the firewall. Nevertheless, there is no problem when you know the cause, but, yesterday I was sure that I have two boards damaged.

Thanks for your quick response and best regards.

Dear all,

It seems that I have the same issue...

Binary sketch size: 1108 bytes (of a 14336 byte maximum)
tools/avr/bin/uisp -v=4 -dpart=atmega168 -dprog=stk500 -dserial=/dev/tty.usbserial-A50018lJ -dspeed=19200 --upload if=/Users/kotobuki/Desktop/arduino-0008/examples/Digital/Blink/applet/Blink.hex

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

  1. press the reset button
  2. press the "Upload to I/O Board" button
  3. the Rx LED blinks once
  4. error message...

My environment is:

  • MacBook (Core 2 Duo 2.16GHz, 2GB RAM, 160GB HD, OS X 10.4.10)
  • Arduino NG rev.C (S/N 9311)
  • Arduino 0008 Alpha

I have no problem communicating with another USB device that also use FT232RL. I also tried different timing (e.g. press the upload button before pressing the reset button etc.) but got no luck. I'll be able to try with another Arduino NG around next Monday, but it would be much appreciated if you give me any suggestions about this issue.

PS
The Arduino Troubleshooting guide says:

Make sure there's a bootloader burned on the Atmega8 on your Arduino board. To check, connect an LED to pin 13 and reset the board. The LED should blink.

Yes, it blinks. But according to several posts in this forum, it should blink 3 times, but mine blinks forever at several Hz. Is this correct?