It seems that many people have seen the error messages I'm getting but not two threads about it seem to have common solution or even explanation of what the problem is. In my case I can no longer upload to either of my UNOs!
Looks like my new UNO has broken my uploading capability...
1 - Uploaded the Blink sketch to my old arduino UNO - worked fine.
2 - Unplugged old arduino UNO and plugged in a brand new one straight out of the box.
3 - Upload FAILED for new UNO.
4 - Changed back to old Uno and upload FAILED.
The new one does have a boot loader installed because the light flashes as you would expect. I can't even flash a new bootloader on there.
Whatever I try to upload I always get this message:
avrdude: stk500_getsync(): not in sync: resp=0x30
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
Windows Vista. I have been paying attention to the COM ports the whole time. Weirdly, my old Uno board has started working again for no apparent reason. The new one that caused this issue in the first place still doesn't work. Interestingly though the old arduino always shows up on COM1 and the new (bad) one comes up on COM3, but even observing this I'm still getting that same annoyingly unhelpful error message I mentioned in the first post.
Pressing the reset button at various times has no effect in solving this.
So I tried all this in Fedora 14...
After a lot of faffing around with groups and permissions and the stupid preferences file, I managed to get code uploaded to both Unos, but the sketch does not execute properly on the chip after uploading, the Blink sketch just sits there with the "L" light on all the time and never blinkks at all.
I've scoured the troubleshooting pages on the website but they don't cover this at all.
Is this something to do with 8u2 firmware? I've seen some mentions of that but not sure if it applies in this case or not?
wossname:
...
Is this something to do with 8u2 firmware? I've seen some mentions of that but not sure if it applies in this case or not?
That message means the downloader software in your desktop (AVRDude) can not handshake with the BootLoader code that it expects to answer nicely on the arduino.
So I THINK the dependencies are:
1- USB Cable
2- Driver / .inf for the USB interface on the arduino (For the particular Operating System).
3- Working USB interface on Arduino (FTDI or in this case the 8U2 Atmel micro doing the USB, and IT's firmware.)
4- Working ATMEL 168/328 chip on Arduino
5- Working Bootloader software on Arduino 168/328
Does anyone have a procedure for dividing and conquering this common and frustrating problem??
@wossname you have covered 1 and 2 with your substitution approach.
You might cover 4 and 5 by physically SWAPPING the 328's on the two Arduinos. UNLESS you have a SMT version.
Keep us posted; this needs to be better understood.
At least by me...
Where'd you get the new Uno (that's giving you problems)? When it appears in the Device Manager, is it shown with a warning icon (yellow triangle, I think)?
How are you uploading to the new board on Fedora? Over the USB cable? If you upload the blink sketch, does the LED ever go off / on (e.g. after 20 seconds or more)?
If one Uno works and another doesn't with the same USB cable, computer, and installation of Arduino, it's likely that there's some problem with the new board. You should probably just contact your distributor and get a replacement.
Does anyone have a procedure for dividing and conquering this common and frustrating problem??
One method to help divide and conquer troubleshooting this kind of problem is to perform a loop back test on the USB serial converter chip (either the older FTDI chip or the newer 8u2 chip). If one jumpers ground to reset pin that will hold the 328 processor in reset condition. Then jumper pins 0 and 1. Now open up the Arduino IDE, then plug in the Arduino and if the 'new' comm port shows up, select that port # and then one can open up the serial monitor. Whatever is send from the monitor's send window should echo back to the monitor's receive window. This at least isolates the problem to a bad AVR chip/missing bootloader, or something in the serial communications path.
mellis:
Where'd you get the new Uno (that's giving you problems)? When it appears in the Device Manager, is it shown with a warning icon (yellow triangle, I think)?
I both my Unos from www.proto-pic.co.uk, which is a sparkfun subsidiary as far as I can tell. Seems a good place to get stuff usually, the staff are helpful and quick, which is why I went there the second time, even though the old arduino (which works perfectly) had some bad solder joints on it which I had to fix myself. As for the Device Manager, there are absolutely no tell-tale differences between one Uno and the other, apart from that they always "prefer" different COM ports. I've only got one USB cable so I've never had them both plugged in together.
mellis:
How are you uploading to the new board on Fedora? Over the USB cable? If you upload the blink sketch, does the LED ever go off / on (e.g. after 20 seconds or more)?
Yeah I'm always using the USB cable, as I don't have any other tools available (programming boards or whatnot).
[fedora only...]
I was fiddling with the sketch code last night. The code is always broken when it gets onto the bad Uno BUT it seems I can alter the way the LED lights up. I cannot get it to run the void loop() function more than once - it's as if it's instruction pointer isn't being incremented after it's returned from the second line of C code. If I go pin HIGH, then delay(1000); then pin LOW the LED stays lit forever. If I reduce that delay to 1ms then the LED lights for what looks like a few milliseconds and then goes off forever. Not sure what is going on there.
[/fedora only]
mellis:
If one Uno works and another doesn't with the same USB cable, computer, and installation of Arduino, it's likely that there's some problem with the new board. You should probably just contact your distributor and get a replacement.
I'm not sure I agree with that on all levels. From my own point of view as an angry consumer I think most people would just want a new one... but from the Arduino project's point of view wouldn't you rather find out what wrong with the product? If I send it back to proto-pic it'll end up in a scrap bin with a post-it note on it saying "broken". I'm happy to try and help diagnose this very aggravating problem if you clever technical chaps are willing to help me with some instructions.
I've just tried the "loop back" test that Lefty mentioned. The Arduino IDE's serial terminal seems to show the exact same behaviour for both boards (see screenshot below). However when I hit enter the good Uno flickers it's TX/RX lights as you'd expect, but the bad Uno does not.
I even tried reseating the 328 chip in it's socket and that doesn't seem to have made any difference, can't say I'm surprised, that was desperation more than anything
OK the loopback seemed OK. But that small difference does seem to point to SOME difference in the two USB micros.
Personally, I would get the antistatic bag an Arduino came it, sit the two Unos on it and use a small screwdriver back and forth a few times, slowly lifting on each end of the 328's and swap them...
That probably is the sensible thing to do but as it stands, I have 1 fully functioning Uno and 1 non-functioning Uno. I don't want to risk wrecking my good one by combining it with bits from a bad one if you see what I mean. Can't really afford to do that.
Dunno, I'm running out of ideas. May be a strange (and rare) manufacturing defect. You could try playing a bit more with uploading different programs under Fedora, e.g. ones that send data over the serial port, or turn on other pins, etc. But it sounds like something is maybe holding the 328 in a weird reset state.
I got this error earlier today! In the Arduino software, look under Tools - Board and make sure it's set to Arduino UNO. It should work fine.
EDIT: Sorry, I just noticed that on the first line, my error was resp=0x00, not resp=0x30. Maybe it's still the same problem?
058606:
I got this error earlier today! In the Arduino software, look under Tools - Board and make sure it's set to Arduino UNO. It should work fine.
I am aware of that thank you. That is not what is causing my problem.
Out of despair and boredom, I decided to have a close look at the board and I think I've found the cause, the underpaid, epileptic baboons that assemble these boards are getting sloppy. See photos below...
One more option: you could buy/order a spare preprogrammed Arduino Uno chip and try that one.
If this does not help, it's almost sure the Arduino board or USB-chip. Having a spare chip is handy in case of problems.
I don't know it this is possible: download the uploaded program, and compare it at binary level (or disassemble) with the uploaded one, would give you at least an idea where it went wrong.
Or install Ubuntu in a virtual system with Aruino and try it?
@Wossname, where are you located? You can buy a replacement 382 chip with bootloader for about 6 to 9 $ US from several places. If you're going to put an Uno On The Shelf, you could order a chip and later see if that's the problem..
And.. when you find a friend with an XP desktop, ask him to load the Arduino SW and try both of your Unos...
It will be interesting to all of us to see the eventual resolution of this set of symptoms. So keep us informed!
I don't know what "Uno On The Shelf" means but I don't want to spend any more money on this than I already have done.
I'll certainly keep you informed, but judging by the photos I just posted (see above), the likely resolution is that this thing is going back to the store for a $refund because asking for a replacement might just get me another broken unit and I'm back to square one minus the return shipping cost. Great.
Consequently my faith in Arduinos on the whole has all but vanished.
