Uno stk500_recv():programmer not responding & stk500_getsync() resp=0x5b

New board identical to Uno. Loaded firmware in ATMEGA16U2 and confirmed that loopback works. Loaded bootloader in ATMEGA328P and the SCK LED blinks 3 times on reset. But I get this error.

What is resp=0x5b? The only change I made from the standard UNO design is I used a 16 MHz crystal instead of the resonator.

================

Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Uno"

Archiving built core (caching) in: C:\Users\Dave\AppData\Local\Temp\arduino_cache_3\core\core_arduino_avr_uno_0c812875ac70eb4a9b385d8fb077f54c.a
Sketch uses 29020 bytes (89%) of program storage space. Maximum is 32256 bytes.
Global variables use 1344 bytes (65%) of dynamic memory, leaving 704 bytes for local variables. Maximum is 2048 bytes.
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM8 -b115200 -D -Uflash:w:C:\Users\Dave\AppData\Local\Temp\arduino_build_667729/MyShadesV3.ino.hex:i

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

Using Port : COM8
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x5b
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x5b

Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
avrdude done. Thank you.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

This resp=0x5b is just incorrect response from target. It is not error code if you think so.
The response:
0x00 (all reads) - no connection at all,
0xFF (all reads) - no connection, possible short circuit on some data wire,
any other value - hard to detect the reason, can be different transfer speed, but in your case same value is permanently read, probably it is not this case.

Which bootloader did you use?
Reset must be prior to upload, automatically from DTR signal. Is it?
Check the oscillation on the XTAL. Probably, it is not this case, but to be sure. If you have no oscilloscope, use the DMM - voltage between XTAL1 pin and GND should be cca half of VCC (square signal 1:1).

I think the average voltage youd see with dmm is lower than that if using the normal crystal option (low power crystal), instead of full swing crystal.

When you do the upload attempt, do you see the triple blink? If not, your reset circuit is wrong.

When you loaded bootloader, did you also set fuses (if you used ide "burn bootloader" function, this was done. If you did it some other way, it might not be (virgin m328p comes with clock set to internal 8MHz, and CKDIV8 set, for 1MHz clock)

DrAzzy:
I think the average voltage youd see with dmm is lower than that if using the normal crystal option (low power crystal), instead of full swing crystal.

Yes, you are right. It is just informative, to detect whether the MCU is started or not.

Thanks for the fast responses.

I checked the dc voltages on the crystal pins. They are 0.75 and 0.46 respectively. I think these are correct because they are the same for the (identical) crystal I am using on the ATMEGA16U2. And I believe the 16U2 is working because when I short the RX and TX lines running between it and the ATMEGA328P, I see the same serial data coming back as I send it with Serial Monitor. This is the loop back test described in http://forum.arduino.cc/index.php?topic=73748.0 However, this note says (step 3) "Force the processor to remain in reset by connecting a jumper from RESET to GND". However, the loopback does not work under this condition; only when the processor is running.

I loaded the serial firmware in the 16U2 using ATMEL FLIP according to the procedure in http://www.pic-control.com/loading-arduino-bootloader-to-brand-new-atmel-microcontroller/. The firmware was Arduino-usbserial-atmega16u2-Uno-Rev3.hex
For the 328P, I used the AVR PocketProgrammer and the procedure given in Installing an Arduino Bootloader - learn.sparkfun.com under the section called Uploading Code the Hard Way (Command line).

For the fuse bits I used:

avrdude -b 19200 -c usbtiny -p m328p -v -e -U efuse:w:0x05:m -U hfuse:w:0xD6:m -U lfuse:w:0xFF:m

and for the flash program and locking I used:

avrdude -b 19200 -c usbtiny -p m328p -v -e -U flash:w:optiboot_atmega328.hex -U lock:w:0x0F:m

I have to say, doing the latter took me the better part of a day before I figured out that I needed to change the path statement in Window 7 so the PC would know where to find avrdude. I also had to put a copy of avrdude.conf which by default is in a different directoy into the bin directory with the avrdude.exe file. I also had to locate the optiboot hex file and put a copy of it into the root directory where the cmd window was open. I tried but never managed to get the loader to work from the Arduino IDE. I keep thinking there HAS to be a simpler way to have done this.

Regarding the SCK LED. It blinks 2 (not 3) times when I push the reset button. When I attempt to upload the program file, it blinks twice but only on the first attempt. I think the Arduino IDE actually tries 10 times before giving up, but the LED only blinks at the beginning of this series. The RXD LED that goes between the 16U2 and the 328P blinks once each time the Arduino IDE attempts to send the program file - that is, it blinks 10 times before giving up. The TXD LED never blinks at all. On the commercial UNOS I have, the SCK LED appears to blink 3 times.

Sorry for giving the wrong number of blinks in my original post. I counted wrong. Maybe this is an important clue.

davidcunningham:
I checked the dc voltages on the crystal pins. They are 0.75 and 0.46 respectively. I think these are correct because they are the same for the (identical) crystal I am using on the ATMEGA16U2. And I believe the 16U2 is working because when I short the RX and TX lines running between it and the ATMEGA328P, I see the same serial data coming back as I send it with Serial Monitor. This is the loop back test described in http://forum.arduino.cc/index.php?topic=73748.0

This looks good.

However, this note says (step 3) "Force the processor to remain in reset by connecting a jumper from RESET to GND". However, the loopback does not work under this condition; only when the processor is running.

The advice is correct, surely. Both MCUs are connected with Rx-Tx. We need 328's pins in high impedance state by keeping the 328 down with RESET pin connected to GND. You can remove the 328 if it is UNO with DIL 328, to get same effect. Try this.

The loopback test does not say anything about reset pulse, which is needed to start the bootloader. You can measure it by DMM on RESET-GND. Significant voltage drop should be observed.

avrdude -b 19200 -c usbtiny -p m328p -v -e -U efuse:w:0x05:m -U hfuse:w:0xD6:m -U lfuse:w:0xFF:m

The only difference I see is EEPROM not preserved hfuse=0xD6 vs. 0xDE (UNO default).

Regarding the SCK LED. It blinks 2 (not 3) times when I push the reset button. When I attempt to upload the program file, it blinks twice but only on the first attempt. I think the Arduino IDE actually tries 10 times before giving up, but the LED only blinks at the beginning of this series. The RXD LED that goes between the 16U2 and the 328P blinks once each time the Arduino IDE attempts to send the program file - that is, it blinks 10 times before giving up. The TXD LED never blinks at all. On the commercial UNOS I have, the SCK LED appears to blink 3 times.

Weird. The optiboot blinks 3x on reset. It is fast flickering. The avrdude it tries 3x before it will give up but it is observable as 1 blink at 115200baud. Try to read out the bootloader and compare it with original HEX.

Regarding shorting the reset for the loopback test, you are of course right. I interpreted the procedure as requiring disabling the reset on the 16U2 which of course will not work. Disabling the 328P reset makes sense.

I fixed the bit on the fuse as you suggested but it made no difference.

Loading the bootloader via the command line appears to work, but the bootloader does not work afterward. That is I cannot load anything through the USB port and the 16U2. So I repeated the loopback test, this time shorting TXD to RXD right at the 328P pins. It again worked indicating the USB, 16U2 etc. was alright.

I then tried loading a different hex file blink.hex into the 328P via command line. It worked. I then loaded blink.hex with bootloader and that ran also. However, the bootloader still would not work.

At this point, I think I have tested everything except the reset that is supposed to come from the 16U2 during a USB load. If I look with my DVM at the DTR signal coming from the 16U2, it goes low throughout the (attempted) load, then returns to high. If I push my reset button, the reset line to the 328P goes low and it resets with 2 fast blinks. What I cannot see with the DVM is whether the reset goes low on the 328P during a load from the 16U2. So I am unable to check the 100 nF cap without a scope. I tired this on a good Uno and couldn't see anything on the DVM there either.

I tried loading my "real" program which is fairly large via the command line as a hex file. It loaded, but produced a verification error each time. However the location of the first error was different every time I tried this. (0x0200, 0x0300, 0x0520). What is going on?

I fixed it!!! The way I figured out what happened is as follows. I used the usbtiny programmer connected to the ICSP on the 328P to load ASCIITable.hex using the command line. This program outputs serial data visible to Serial Monitor. In my case, I received the data but it was somehow hosed up with all non ASCII characters no matter what baud rate I selected in Serial Monitor.

So I concluded the problem had to be in the USB serial interface in the 16U2. I had loaded it using the ATMEL FLIP software, and it passed the loop back test, so I figured it must be OK. But something was messed up. Anyway, I reloaded the 16U2 firmware using the usbtiny programmer connected to the ICSP on the 16U2 using commands based on the document https://www.instructables.com/id/How-to-Restore-the-Arduino-UNO-R3-ATmega16U2-Firmw/

I kept getting verification errors until I slowed the load process down by using the -b 19200 command. Then VOILA it loaded and now I was getting correct serial data out.

With the 16U2 working correctly, I can now load my program using the Arduino IDE and it works!

Thanks to all who helped.