I just received my hew Uno board. After connecting it to my MAC I uploaded the blink program and all went well.
I modified an example, uploaded it and received the messages
Binary sketch size: 2278 bytes (of a 32256 byte maximum)
avrdude: stk500_getsync(): not in sync: resp=0x86
avrdude: stk500_recv(): programmer is not responding
Can someone explain this, or heaven forbid there may be a webpage with all the messages and their explanations?
There is a troubleshooting guide that touches on this:
http://arduino.cc/en/Guide/Troubleshooting
Search for "programmer not responding."
When auto-reset fails, you'll usually see that message. Press and hold the press button. Click the upload button in the Arduino IDE. When the "Sketch: xxx of xxx bytes" appears, release the button.
I've attempted that with the blink program and it worked, so I tried it with my modified program to read a potentiometer and display the value with serialwrite. I verified the program, presses the reset button for several seconds, then hit the upload button. It produced the same error message as before, and when I clicked on the serial monitor button it hung up my wireless trackball on the MAC. I had to physically unplug the Mac, resstart it an reload all the programs. This happened twice.
There is an issue with the Uno and sending too much serial data (and/or sending data before the 8u2 is ready). The root resolution is to update the 8u2.
Modify the approach I gave you above. Unplug the Uno from Power before pressing and holding the RESET button. Plug in power and hold reset until right before the upload actually begins. It is tricky but you can eventually make it work.
Once you've done that, add a delay(500) in your setup() function. This will keep the Uno from sending data to the 8u2 before it is ready.
I went back to the blink program and went thru the procedure of disconnecting & reconnecting the USB, press reset while verifying the sketch, then uploading. But I still get the messages
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'm using \dev\tty\usbmodem0000113D1, and this is Arduino 0022 and Mac OS 10.4.11
Changing the sketch in the IDE doesn't matter until you have successfully re-programmed the Uno.
You just have to learn the timing between when the "Binary sketch size:" message appears and the actual upload attempts to start. You'll usually see the RX light on the Uno flash a couple of times before the software gives the "not responding error." Count how many seconds it takes for that to occur. As an example if it is 2 seconds, then wait 1 second until after the "Binary sketch size" message appears.
Effectively, you need to hold the Uno in RESET until your Mac is ready to upload to it.
I held the reset button down until the Binary sketch size message appeared and the blink sketch uploaded with no error message.
So I went to my potentiometer sketch with no serial code, adjusting the blink timing as per the value read from the pot. Held the Reset down until the binary sketch message appeared. The Rx light came on, then 4-5 seconds later the error message appeared, followed by the second message after another 4-5 seconds.
The sketch is as follows
int sensorPin = A0; // select the input pin for the potentiometer
int ledPin = 13; // select the pin for the LED
void setup() {
// declare the ledPin as an OUTPUT:
pinMode(ledPin, OUTPUT);
// Serial.begin(9600);
}
void loop() {
// read the value from the sensor:
delay(2000);
int sensorValue ; // variable to store the value coming from the sensor
sensorValue = analogRead(sensorPin);
// Serial.print(sensorValue);
// Serial.println();
// turn the ledPin on
digitalWrite(ledPin, HIGH);
// stop the program for milliseconds:
delay(sensorValue1000);
// turn the ledPin off:
digitalWrite(ledPin, LOW);
// stop the program for for milliseconds:
delay(sensorValue1000);
}
After tinkering with it some more, I can get it to download about 25% of the time. Thanks!
I also had the same problem (on Linux; Fedora 13 with brand new Arduino Uno R2), and finally solved it after debugging for a few days. The critical bit of the solution was just to plug Arduino directly into my computer's USB port, instead of Apple Cinema display USB hub port! And also use arduino-0022 and its avrdude binary (which is apparently modified from standard avrdude to support Arduino).
Some infobits that I discovered while debugging this:
The "not in sync: resp=0x86" error stems from the fact that the default program contained in my Arduino as shipped prints a string of bytes (beginning with 86 hex) into the USB connection. The string is (in hex): 86 18 18 00 86 86 00 18 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06 06 fe 66 18 18 fe 66 18 18 fe 66 78 06 fe 9e 00 18 06 66 66 f8 98 00 fe 98 00 fe 66 00 18 fe 66 1e 18 7e 00 78 00 06 78 00 18 78 00 (in 7N1 serial data format, this actually contained an intelligible string "Standarda_2_2_forUNO_0_3"). So the "not in sync: resp=0x86" effectively means that the optiboot bootloader on Arduino has gave up waiting for input from USB (it waits for input for 500ms), and has started the user program. After that there is no hope of uploading anything, before the Arduino is reset.
Uploading the latest 8U2 firmware via dfu-programmer did not improve anything. Still the same symptoms.
Experimenting with pressing the reset button before/while/after uploading (or while plugging the USB cable in) did not fix the problem in my case, although it sometimes changed the error message, and with upload.verbose=true in ~/.arduino/preferences.txt I saw that avrdude sometimes managed to issue a couple of commands successfully to Arduino, but then it again got a 0x86 response before upload could be completed.
In fact the problem was caused by about 70% of commands on the USB being somehow randomly dropped. Since avrdude needs to issue more than 10 commands to successfully upload the program, it had a very low chance of succeeding, even though it sometimes managed to issue the first few commands. And as soon as 500ms are passed without any successful command, the bootloader starts the user program and the dreaded 0x86 byte is received. Here is a Perl script I wrote to debug the issue:
#!/usr/bin/perl
use strict;
use Device::SerialPort;
use Time::HiRes qw ( time sleep );
my $port = Device::SerialPort->new("/dev/ttyACM0");
my $start_time=time;
# $port->dtr_active(0);
$port->databits(8);
$port->baudrate(115200);
$port->parity("none");
$port->stopbits(1);
$port->read_const_time(20);
$port->write("0 ");
sleep(0.55); # In my tests, this had to be 0.45..0.95, otherwise almost no responses are received
$port->input;
my $last_recv=time;
my $recv_count=0;
my $send_count=0;
while ($recv_count < 100) {
$port->write("0 "); # stk500 protocol STK_GET_SYNC command
$send_count++;
my ($count,$string_in)=$port->read(1);
if ($count > 0) {
$string_in.=$port->input;
$last_recv=time;
$recv_count++;
}
last if (time-$last_recv > 1.5);
}
print "$recv_count $send_count\n";
If everything works, it should print "100 100" (meaning it sent 100 commands to bootloader and got 100 responses). But when Arduino is plugged into Apple Cinema USB, it prints something like "31 100", meaning only 31 responses were received, or even something like "9 40", meaning the bootloader gave up even before it managed to send 100 commands. Both conditions are symptoms of the "packet loss" problem, which was ultimately solved by not using the Apple Cinema USB hub.