Can't upload to Nano clone (DIYino)

I grabbed an awesome DIYino from Protonerd to use in my Lightsaber project. The test sketch it came loaded w/ worked fine, even after soldering up all my LEDs, switches, etc. When I try and upload to it however, I get the dreaded avrdude: stk500_recv(): programmer is not responding error. However, if I unplug the arduino, hit upload, wait for the compilation, and time it just right to plug the board back in, it’ll upload. This works about 1 in 10 tries.

I read somewhere that this could be caused by a short, so I unsoldered everything to start fresh. No luck.
I tried several different sketches with no luck.
I tried 3 USB cables. No luck.
I hooked up a genuine Pro Mini with all 3 aforementioned USB cables and they all worked fine.
I tried using different AVR Board versions (1.6.7-current), also to no avail.
I tried different IDE versions, again nothing.
Confirmed multiple times that Board and Port are selected properly.
Installed the IDE on a Windows 7 computer and tried uploading. Nope.
Installed the IDE on a Windows 10 virtual machine. Nada.

Upon plugging in, I have a blue LED on at the bottom (end away from the USB), and a red LED to left of the USB port solidly lit, and to the right of the USB port, a green LED blinks a few times when initially plugged in, and then nothing.

During upload, whenever the IDE prints the avrdude error, a second LED to the right of the USB port flashes orange.

I know that those details don’t mean a huge amount since this isn’t a genuine Nano, but it might lend some context.

Anyhow, attached is the full, verbose output from an upload, and below the horizontal rule is the juicy part (so far as I can tell) so any hints or advice or ideas would be great!

thanks in advance,
-jason


/home/jshaw/Downloads/arduino-1.6.11/arduino-builder -dump-prefs -logger=machine -hardware

prefs=runtime.tools.avrdude.path=/home/jshaw/.arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5 -prefs=runtime.tools.avr-gcc.path=/home/jshaw/.arduino15/packages/arduino/tools/avr-gcc/4.8.1-arduino5 -verbose /home/jshaw/lightsaber/LightSaberOS/LightSaberOS.ino
/home/jshaw/Downloads/arduino-1.6.11/arduino-builder -compile -logger=machine -hardware /home/jshaw/Downloads/arduino-1.6.11/hardware -hardware /home/jshaw/.arduino15/packages -tools /home/jshaw/Downloads/arduino-1.6.11/tools-builder -tools /home/jshaw/Downloads/arduino-1.6.11/hardware/tools/avr -tools /home/jshaw/.arduino15/packages -built-in-libraries /home/jshaw/Downloads/arduino-1.6.11/libraries -libraries /home/jshaw/Arduino/libraries -fqbn=arduino:avr:nano:cpu=atmega328 -ide-version=10611 -build-path /tmp/builddac5d34d00ca7008f08e4d6cb950662d.tmp -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avrdude.path=/home/jshaw/.arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5 -prefs=runtime.tools.avr-gcc.path=/home/jshaw/.arduino15/packages/arduino/tools/avr-gcc/4.8.1-arduino5 -verbose /home/jshaw/lightsaber/LightSaberOS/LightSaberOS.ino
Using board ‘nano’ from platform in folder: /home/jshaw/.arduino15/packages/arduino/hardware/avr/1.6.7
Using core ‘arduino’ from platform in folder: /home/jshaw/.arduino15/packages/arduino/hardware/avr/1.6.7
WARNING: Category ‘’ in library EEPROM is not valid. Setting to ‘Uncategorized’
WARNING: Category ‘’ in library SPI is not valid. Setting to ‘Uncategorized’
WARNING: Category ‘’ in library SoftwareSerial is not valid. Setting to ‘Uncategorized’
WARNING: Category ‘’ in library Wire is not valid. Setting to ‘Uncategorized’
Warning: platform.txt from core ‘Arduino AVR Boards’ contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} “{build.path}/{archive_file}” “{object_file}”, automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} “{archive_file_path}” “{object_file}”. Consider upgrading this core.
Detecting libraries used…

Using library light_WS2812 in folder: /home/jshaw/Arduino/libraries/light_WS2812 (legacy)

Sketch uses 28,282 bytes (92%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,136 bytes (55%) of dynamic memory, leaving 912 bytes for local variables. Maximum is 2,048 bytes.
/home/jshaw/.arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/bin/avrdude -C/home/jshaw/.arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB2 -b57600 -D -Uflash:w:/tmp/builddac5d34d00ca7008f08e4d6cb950662d.tmp/LightSaberOS.ino.hex:i

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 19:04:16
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is “/home/jshaw/.arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/etc/avrdude.conf”
User configuration file is “/home/jshaw/.avrduderc”
User configuration file does not exist or is not a regular file, skipping

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

avrdude done. Thank you.

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

arduino-log.txt (37.9 KB)

jshaw: if I unplug the arduino, hit upload, wait for the compilation, and time it just right to plug the board back in, it'll upload. This works about 1 in 10 tries.

That indicates a problem with the auto reset. After reset or power on there is a short window of time that the bootloader is waiting for an upload. Normally the reset signal is sent from the IDE to the board to activate the bootloader at just the right time for the upload to start. By plugging the board in at just the right time you are manually doing this. In the old days the Arduino boards didn't have auto reset and you had to press the reset button to upload.

Thanks for the response, pert! Protonerd informed me of what pins are involved in the FTDI reset, so I'll be getting out the magnifying glass and trying to follow those traces and pins to see if I nicked anything while soldering.

Should have a followup tonight or tomorrow.

pert: That indicates a problem with the auto reset. After reset or power on there is a short window of time that the bootloader is waiting for an upload. Normally the reset signal is sent from the IDE to the board to activate the bootloader at just the right time for the upload to start. By plugging the board in at just the right time you are manually doing this. In the old days the Arduino boards didn't have auto reset and you had to press the reset button to upload.

Hi pert, I need your expert opinion: could it be, that the bootloader of the Atmega got corrupted and it causes the upload difficulties? Would such a case produce a similar fail behaviour?

Jason, do you have access to another arduino board (Nano?) and a 10uF cap?

It's unlikely that the bootloader could be corrupted in such a way that it will still work sometimes but not other times. Reburning the bootloader is easy enough so I suppose it''s worth a try. It's more likely to be something related to the auto-reset hardware or signal.

I think I found the problem. On the SD Card side of the board, adjacent to the GRND pad, beside SPK2, there's a line that appears to be severed, due to sloppy soldering on my part.

I'm hoping to pick up one of those pens that writes with conductive "ink" and see if I can carefully reconnect it this weekend.

This raises a question for me about best practices. There are 3-4 wires that all need to go to GRND over there, so what's the best method for wiring them? I tried soldering two on top and two on the bottom of the board (or 2 and 1 maybe), but that obviously means a lot of clutter in a very tiny area.

Hi Jason,

Can you send me a photo of the location on the PCB which got severed? Then I can look up it if it plausible to explain the erronous behaviour.

For the time being I will hold back the new board, but let me know if you cannot fix it, I will send a replacement asap.

Google Photos

Google Photos

Here are front and rear pics of my board. What I thought was a broken connection was actually some flux that wiped away easily while inspecting the board.

Maybe someone with more knowledge will spot a problem, as I’ve had no luck.

Jason

I'm starting to be intrigued by this board... as I'm working currently as a Quality Manager and deal quite often with field returns, now I can have one form my very own project. Nothing to be overly proud about (I mean the broken board), but it's a challange and I'm sure I can learn something out of it about just how robust this product is.

Jason, replacement board will go out in the coming days, please send me back the broken one. I cannot spot any mistake on your part based on the pics.