avrdude: stk500_recv(): programmer is not responding

Development Tools IDE 1.x
1

Guys I really need help on this one.
I was working on this project with my pir sensor, infrared sensor. disconnected it from the computer to try it with my 9v and the reset button wouldn't work, and pin 13 my led wouldn't go on. I believe it's something hardware - software.
The symptoms are:

  • Reset button doesn't work. Apparently...
  • Led on pin 13 does not go on.
  • TX doesn't go on.
  • RX only goes on for a sec when I try to upload.
  • I can't upload any sketch.

Only the green on Led goes on. And I get "avrdude: stk500_recv(): programmer is not responding" as an error.
Im working with:

  • Leopard for mac osx 10.5.8
  • Usb cable
  • Arduino 0022
  • Arduino uno

I tried everything I could. I really can't afford another arduino now, and I need to have it working for my school science fair!
I hope you guys can help me :frowning:

2

Have you tried disconnecting the battery and the +5v to the sensor circuit before uploading?? I had a similar problem with a midi input circuit. It was fixed by uploading the program with the power from the arduino board disconnected from the midi circuit...it might work (im no expert though..)

3

Mubase:
Have you tried disconnecting the battery and the +5v to the sensor circuit before uploading?? I had a similar problem with a midi input circuit. It was fixed by uploading the program with the power from the arduino board disconnected from the midi circuit...it might work (im no expert though..)

Yes, I disconnected all connections of the arduino. Even re-installed the software.
Thanks still.

4

Hello Tobias,

I'm facing a problem very similar to yours in which I can't upload sketches to my board.

I have an UNO as well, and I have tried with versions 0022 to 1.0 without success. I am currently running OS X 10.6.8 "Snow Leopard" and also tried on Ubuntu 10.10 but I had the same discouraging result.

This is the error I get when I try to upload any sketch:

Binary sketch size: 1018 bytes (of a 32256 byte maximum)
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

I have found in my research many posts pointing at this same error but many go unanswered.

As I have read in many articles the problem in some cases resides on the MEGA8U2 chip (the little one in front of the USB metal socket) that came with a buggy firmware in early UNO versions. So I tried this to see if it would solve it:

…but it wouldn't want to enter DFU mode (may be in your case it could work) even though I tried alternative and derivative techniques. Speaking about me, the problem started when I loaded code that communicated values from the accelerometer inside a Wii controller via I2C to the computer and this caused the serial interface in the arduino to enter an endless loop, ergo, preventing it from uploading new sketches.

Perhaps your PIR sensor was sending data to the Serial Monitor in the arduino environment and that triggered the bug. (Some time ago I used one of those with a healthy arduino to receive infrared control codes and visualize them on a serial monitor, so that's my guess on a possible root for your problem)

I even have attempted burning a nice clean bootloader via a working board loaded with the ArduinoISP sketch but again no success. :frowning:
Later I realised I was not hitting the right spot with this move, since the processor (the big ATMEGA328P chip) already has a working bootloader then the offending system is the USB interface itself.

I guess our last hope is to find some computer with Win-XP and see if once there it decides to work. After all, they are the most common in our country so I can't see why not give it a chance. By the way, it is actually plausible that it'll make it on that operating system; I have read that Mac OS X and other *NIX systems handle the Arduino resets differently (including your OS version leopard). I need my Arduino working too since neither I can afford a new one.

I hope you luck :smiley: and keep us updated if you find any solution from your part.

P.S. at the moment I'm looking for ways to program the MEGA8U2 chip directly from the empty ICSP headers that are close to it on my board and see if it solves this issue once for all.

5

sigui-ion:
Hello Tobias,

I'm facing a problem very similar to yours in which I can't upload sketches to my board.

I have an UNO as well, and I have tried with versions 0022 to 1.0 without success. I am currently running OS X 10.6.8 "Snow Leopard" and also tried on Ubuntu 10.10 but I had the same discouraging result.

This is the error I get when I try to upload any sketch:

Binary sketch size: 1018 bytes (of a 32256 byte maximum)
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

I have found in my research many posts pointing at this same error but many go unanswered.

As I have read in many articles the problem in some cases resides on the MEGA8U2 chip (the little one in front of the USB metal socket) that came with a buggy firmware in early UNO versions. So I tried this to see if it would solve it:

http://arduino.cc/en/Hacking/DFUProgramming8U2

…but it wouldn't want to enter DFU mode (may be in your case it could work) even though I tried alternative and derivative techniques. Speaking about me, the problem started when I loaded code that communicated values from the accelerometer inside a Wii controller via I2C to the computer and this caused the serial interface in the arduino to enter an endless loop, ergo, preventing it from uploading new sketches.

Perhaps your PIR sensor was sending data to the Serial Monitor in the arduino environment and that triggered the bug. (Some time ago I used one of those with a healthy arduino to receive infrared control codes and visualize them on a serial monitor, so that's my guess on a possible root for your problem)

I even have attempted burning a nice clean bootloader via a working board loaded with the ArduinoISP sketch but again no success. :frowning:
Later I realised I was not hitting the right spot with this move, since the processor (the big ATMEGA328P chip) already has a working bootloader then the offending system is the USB interface itself.

I guess our last hope is to find some computer with Win-XP and see if once there it decides to work. After all, they are the most common in our country so I can't see why not give it a chance. By the way, it is actually plausible that it'll make it on that operating system; I have read that Mac OS X and other *NIX systems handle the Arduino resets differently (including your OS version leopard). I need my Arduino working too since neither I can afford a new one.

I hope you luck :smiley: and keep us updated if you find any solution from your part.

P.S. at the moment I'm looking for ways to program the MEGA8U2 chip directly from the empty ISP headers that are close to it on my board and see if it solves this issue once for all.

Thank you so much, I will have to try this method. I went to a micro controller help place and they told me it might be the 328. The best thing will be to buy a new one. And when I get my internet back I will try this definitely. I will keep you up to date. Maybe it is not the bootloader....

Thanks
Tobias A. :wink:

6

I am having the same problem. Can't upload sketches to the Uno at all! I have sourced another Uno, and am going to try it out, but I am concerned I am going to cause the same problem twice and ruin another board. Yay or Nay?

7

Worst case if you are using an arduino uno http://arduino.cc/en/Main/ArduinoBoardUno
and it is in fact the ATmega328 just buy a new ATmega328 for $5 (that's why it's socketed)

Have you looked at Tools/Serial Port and does it show that there is one ? like /dev/tty.usbserial-FTxxxxx?
My experience has been that removal and reinserting sometimes changes the name.

From a terminal (shell command prompt) issue:

ls -l /dev |grep usb

Do your get something like:

crw-rw-rw-  1 root     wheel      18,  27 Apr 16 17:20 cu.usbserial-FTFO9AFU
crw-rw-rw-  1 root     wheel      18,  26 Apr 16 17:20 tty.usbserial-FTFO9AFU
8

Yes I do have two Serial Ports showing:

This is what happened when I issued that prompt to Terminal:

Last login: Mon Apr 16 07:57:33 on console
Zachary-Siegels-MacBook-Pro:~ zacharysiegel$
Zachary-Siegels-MacBook-Pro:~ zacharysiegel$ ls -l /dev |grep usb
crw-rw-rw- 1 root wheel 11, 19 Apr 17 00:11 cu.usbmodem411
crw-rw-rw- 1 root wheel 11, 18 Apr 17 00:11 tty.usbmodem411
Zachary-Siegels-MacBook-Pro:~ zacharysiegel$

I just tried my other Uno, and it works. What does this mean? Is it the ATmega328 or is it the other chip, the MEGA8U2. Also, my failing Uno is running version 1.0 firmware, whereas the working one is running 0.0.

I was looking at trying one of these, but I am concerned I am just going to ruin things and it will never work:

Should I do either?

9

Tobias00:
I went to a micro controller help place and they told me it might be the 328. The best thing will be to buy a new one.

Indeed... Please let me know if that helps, we're in luck for the chips on our boards are easily swappable; I have since bought a new UNO and now comes with an SMD chip which in my view are rather hard to replace.

dgerman:
it is in fact the ATmega328 just buy a new ATmega328 for $5 (that's why it's socketed)

I see a glow of hope here

zsiegel:
I just tried my other Uno, and it works. What does this mean? Is it the ATmega328 or is it the other chip, the MEGA8U2. Also, my failing Uno is running version 1.0 firmware, whereas the working one is running 0.0.

I was looking at trying one of these, but I am concerned I am just going to ruin things and it will never work:

http://arduino.cc/en/Hacking/DFUProgramming8U2

http://arduino.cc/en/Tutorial/ArduinoISP

Should I do either?

My new one works too, but inversely it's running 1.0 and the one in coma has v0.0 on it, now the first tutorial in the links states that if 1.0 is showing as the device's firmware version on System Profiler it is not necessary to attempt the upgrade.

On the other hand I was looking for the possibility that the second tutorial could lead me across the process of directly upgrading the 8U2 chip, if it's actually the offending one. I get the feeling in your case that such a situation does not quite fit, then trying the suggestion from the person above would be the way to go, (I'm trying that as well soon, plus I want to learn how to program an ATMEGA that I knwo fuctions correctly, on a breadboard :P) the only thing that leaves me thinking is that it looks as though he's using an FTDI based board instead of the 8U2 one like us, -by looking at the posted terminal response- but well then, that might be irrelevant anyway it's just I noticed that.

My response to: ls -l /dev |grep usb is like yours (cu.usbmodem) since the UNO is detected as a modem, unlike a Lilypad I have around which presents itself as: cu.usbserial for it has an FTDI chip for communicating with the computer.

What I am pointing out is that the command was to see if there was indeed a board detected by the system and there is[?], but it is not specific and he could have ignored the problem concerning the bus these UNOs use. Also, this sir is right, I have seen the same behaviour when disconnecting and replacing the ATmega328 again on its socket: it causes the board to reset and comes with a different port number i think of it as a clue aside from the normal function it is. There is still scarce knowledge as to what causes it but it may well be due to a more general issue like a bad solder or something. Of course it's not that expensive so it makes sense being sure whether it's that or not (we get an extra chip to play with anyway) yet if it's possible to save a coupla' coins then it's cool. Take for sure my comments or any other's as a grain of salt though, decision is up to one's self.

Good luck everyone!