Arduino UNO Rev3 Damaged Bootloader?

I am pretty new to the Arduino scene, and I just bought my UNO a couple weeks ago. It's been working fine (great actually) until this evening. I was experimenting with a brushless RC car motor, trying to get it to run off of the Arduino power (connected to a 12V DC plug). Anyway, I gave up on it and went back to an LED project. Upon trying to upload my sketch, I got the infamous "avrdude stk500_getsync() not in sync" error. Now I had gotten that error once before by trying to "upload with programmer", but I double checked my settings and kept trying to upload the sketch. Each time I got that error.

After doing some research, it appears as though my boot loader is damaged. Here are the criteria I matched my issues up with online:

  • RX/TX lights do not flash on upload
  • RESET button does not flash lights
  • Loopback test fails

Now I am ready to go out and get supplies for a parallel programmer to burn the boot loader back, HOWEVER, I want to know if that would indeed fix it. Maybe the problem is not the boot loader? And if not, does anyone have any suggestions?

Thanks!

Loopback failing is usually a sign of more significant damage than just the bootloader. It could be the xxu2 usb chip has lost its firmware as well, or you could have even more damage.

It is unlikely the bootloader has been corrupted. More likely your experiments have damaged something. (We all do that!)

You might be better off spending your money on another Uno board. Then you can use that to check the first one, and if it is cactus, well, now you have a replacement.

You can use this to check one board with another one:

http://www.gammon.com.au/forum/?id=11633

trying to get it to run off of the Arduino power (connected to a 12V DC plug).

For future reference, it might help to describe in greater detail what you were doing. So we can help you not do it again. :)

The easiest board to make is the deaduino. I postulate a certain tier of success here can only be reached from the top of a sufficiently high pile of dead hardware. My software background serves me well here in that I usually have some kind of trail of evidence that lets me know when a board died, so I don't waste more than two or three weeks reproducing the problem :P