Hello fellow Arduino fans,
I hope this post will not be seen as being too long.
It has been well considered and my first.
But ... be warned it is yet another one that broaches the vexing and elusive
avrdude: stk500_getsync(): not in sync: resp=0x00 programming issue.
After many late night Google sessions reading whatever I could find on this topic, it seems there can be many causes for this fault condition and despite the UNOs apparent simplicity can prove quite difficult to overcome.
It is my sincere hope that this posting will entice Nick Gammon and other gurus to offer some pearls of of thier respected and collective wisdoms in relation to this seemingly common and troublesome issue.
It strikes me, in my case anyway, that the solution is probably staring me in the face and whilst I am relatively new to this microprocessor caper, Arduino style, I am no stranger to component level service and repair in another field of electronics and invariably and unavoidably aware of the role microprocessors play in just about every modern appliance ... our gear is full of the blighters too.
I would also like to think I can use test equipment and soldering equipment adeptly.
So it is with a certain degree of humility I post my story ...
As an educational challenge I purchased a known to be defective UNO card without 328 from ebay.
I have several other working 328 cards, a mixture of genuine, clone and veroboard DIY jobs and all work great and lend themselves as useful test and programming beds so bootloading using Nick's excellent tutorial and associated sketches made bootloading several new Tayda chips no challenge.
These Optibootloaded 328s have been tested and work fine in other working UNO boards.
Reflashing of the USB serial IC was also sucessful using flip, with subsequent loopback testing confirming the front end to be working and visible in XP Device Mangler.
If I load Blink using another UNO and place that 328 in the faulty board it blinks.
I then placed a new and freshly bootloaded chip in it's place and correctly setup the 1.05 IDE and attempt to upload blink ... sync error.
I am able to flash both chips using AVRisp mk II into iscp ports but have not tried with my usb ftdi programming cable serially, this may be a worthwhile test?
I have checked regulator voltages and checked track and plate through hole continuities and reflowed what can only be described as very ordinary surface mount soldering.
I paid particular attention to trackwork leaving the 16U2 USB serial convertor chip (pins 8 and 9) right through to pins D0 and D1 and to the 328 socket pins 2 and 3 with the trusty Fluke (with the 328 removed).
For all money it looks like the 16U2 is crook but still passes loopback test?
The only other possibility I can see is something odd going on with the DTR line on pin 13 of 16U2 but manual resetting attempts have proven fruitless.
I have not gone so far as to dust off the CRO yet but it seems I good idea to do some comparative waveform checks on the auto reset and serial data lines
What do you guys reckon?
I look forward to your comments and suggestions ...
Many thanks and happy Arduining.
Hello again,
It is hard not to be disappointed at the lack of response to my previous post.
As it is now the weekend I am able to dedicate some time to this problem but really am at a loss as to what my next step should be.
I am not looking for a one click solution here, just some guidance.
Maybe a checklist or maybe a suggestion to alert me to something I've overlooked or failed to read ... anything.
Thank you once again.
The remaining possibilities...
• Resonator is not producing a viable clock signal. Does L blink three three times when you release the reset button?
• Auto-reset is not working and you did not get the timing right when you tried to manually reset.
First of all, please accept my sincerest thanks for responding to my post, Coding Badly 
Your suggestions are not only sound but also very much appreciated.
Should the reference oscillator be the culprit, I am intrigued by your interest in the behavior of the LED in response to release of the reset button, which does flash rapidly three times as you suggested.
Is such a response indicative of an "OK" crystal or resonator?
Does an off frequency, fully active resonator have the potential to cause as much havoc as completely defective inactive one?
Should it be necessary to replace this device, another 16 MHz crystal similar to the 16U2 osc. 'could' be successfully substituted ... couldn't it?
If on the other hand, it is the auto reset that is defective, does this necessarily mean that the 16U2 is history?
Is the possibility of an incorrect value or faulty component (C5/RN2D) on the DTR line messing with the reset pulse timing/duration worth entertaining?
Finally, if 16U2 pin 13 is at fault, are such localized failures in these chips commonplace or do they completely "leave the building" upon failure?
Of course the possibility of missing the manual reset window has not been completely discounted ... particularly given the degree of luck I have had thus far with this project!
Again my thanks and eagerly await your response.
Hello,
I thought a quick update may be of interest.
I removed the resonator on the 328 and fitted a 16 MHz crystal and 22pF caps in its place.
I also replaced C5.
This work resulted in no change.
It does appear that the IDE/16U2 combination is successfully initiating the auto reset sequence as indicated by three blinks of 'L' followed by three slower blinks of the RX Led and then the sync error, at no time does the TX LED flash.
I also once again tried many manual resets, removed the 328, read and verified the bootloader on it was still O.K. and again performed a successful loopback test.
Interestingly, I am unable to program this card using an my USB FTDI programming cable - this 'must' be the most significant indicator as to what is wrong here.
There does remain uncertainty in my mind in relation to the correct way to connect the RTS line from this programming cable to the UNO.
I am now at a total loss, but remain determined to overcome this issue, what have I missed?
Thanks again.
I can't believe nobody wants to help me out with this?
oinduino:
Should the reference oscillator be the culprit, I am intrigued by your interest in the behavior of the LED in response to release of the reset button, which does flash rapidly three times as you suggested.
Is such a response indicative of an "OK" crystal or resonator?
The fact that the LED blinks indicates the resonator is producing a click signal. The rapid blink is a sign the clock signal is close to the correct speed. Were I in your shoes I would assume the clock signal is not the problem.
If on the other hand, it is the auto reset that is defective, does this necessarily mean that the 16U2 is history?
That is one possibility.
There is a capacitor, resistor, and diode on the reset line. I doubt the resistor or diode would cause problems but a damaged capacitor could.
Is the possibility of an incorrect value or faulty component (C5/RN2D) on the DTR line messing with the reset pulse timing/duration worth entertaining?
My guess is yes for capacitor no for the resistor (unless the resistor is short-circuit; which may not even be possible).
Finally, if 16U2 pin 13 is at fault, are such localized failures in these chips commonplace or do they completely "leave the building" upon failure?
"Commonplace" is not an appropriate word to describe the failure of an AVR processor. If any failure was commonplace, Atmel would have long ago gone out of business.
It is certainly possible for an AVR processor to partially fail (e.g. one pin no longer function as an output). I have one on my desk with a failed AREF pin. As far as I can tell everything else on the processor works correctly.
Of course the possibility of missing the manual reset window has not been completely discounted ... particularly given the degree of luck I have had thus far with this project!
Hold the reset button. Click Upload. Release the reset button the moment the IDE displays "Uploading" in the status area.