[Solved] Programmer not responding Arduino Nano 328p after uploading a sketch

Hey guys, so here is an interesting one:

When I upload a specific sketch I wrote, I can't upload anything else, because of "programmer not responding"

Short story about this:
I've got an arduino nano to test my sketches before deploying it on the one i actually use. So when testing a sketch, I can't upload anything else afterwards. So I ordered new clones and I've got the same problem. I uploaded the blink sketch on all new ones to see if they work, which was successful, but after uploading my sketch to one of them it too locked up and said "programmer not responding" like the other one. So it looks like my sketch is bricking arduinos.
I've identified that the error lies within a class I've written so i gotta look into where exaclty some time, but the arduinos are the bigger problem now.

This happened to two boards as of now, but I can still upload the normal blink sketch to other boards.

Here is what I've tried while trying to upload "blink":

  • Uploading on Linux Mint and Windows 7
  • Pressing the reset button before uploading
  • Pressing the reset button, unplugging, plugging in, releasing the reset button, uploading

Some extra info:

Upload error bricked Board:

Build options changed, rebuilding all
Sketch uses 930 bytes (3%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
/usr/local/bin/arduino-1.8.7/hardware/tools/avr/bin/avrdude -C/usr/local/bin/arduino-1.8.7/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB1 -b57600 -D -Uflash:w:/tmp/arduino_build_674927/Blink.ino.hex:i 

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/usr/local/bin/arduino-1.8.7/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/home/myusername/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB1
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file "/tmp/arduino_build_674927/Blink.ino.hex"
avrdude: writing flash (930 bytes):

Writing | avrdude: stk500_recv(): programmer is not responding
######avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

The Board still receives serial input, because when sending something inside the serial monitor the rx led blinks once.

They are Arduino Nano 328p clones (newest one from elegoo) and they've been working using the 328p (Old bootloader).

I only got Arduino Nanos inhouse.

Any way to maybe clear the storage, so that no program is on there to execute?

Hope you guys can help.

Best regards

(deleted)

spycatcher2k:
Choose 328 old bootloader from the tools menu.

5chmidti:
...
They are Arduino Nano 328p clones (newest one from elegoo) and they've been working using the 328p (Old bootloader).
...

That's not the old/new bootloader error anyway. Look at the output! it started writing and then choked!

That is very strange behavior. I've only seen similar behavior once, on an attiny85 that was missing the decoupling cap.

Does the LED blink again during the upload at the point that it fails? (implying it got reset at that point)

Is the power supply really dodgy or something?

Could there be a problem with Vcc of chip not connected to power (ie, defect or damage to board), so the chip is only running by being backpowered through the serial pins, so it resets when it tries to commit the first page (which results in a current spike that would reset the chip if it was only running from the back-powering from the serial line? It looks like it's crashing right about at the point....

Looks like I've bricked another one with that sketch. And it looks like I've got 3 different problems (the other two have the getsync attempt error with the programmer not responding), but lets focus on the one described in the original post.

So here is what happens when uploading:

  • Hitting upload
  • output gets to "overriding baud rate ..."
  • then the L led flashes once
  • rx and tx flashing 3 times simultaneously and fast
  • the rest of the upload log gets put out
  • then it starts hanging at the writing point while the L led is lit up quite dim

I've only powered these new boards via usb.

(deleted)

I am, but i don't know if that would be so feasible for 3 cheap nanos (I think 9 eur or something for shipping one way).

Anything else I should try?

(deleted)

Anything else I should try?

Maybe check this out.

"$ systemctl status

That returns a tree of all the services that your system is running. Look through that list to see if there are any “serial-getty” services running. If there are you should remove them:

$ sudo systemctl stop serial-getty@ttyACM0
$ sudo systemctl disable serial-getty@ttyACM0

While you’re there look through the list for another troublesome member: ModemManager. This is a program used to dial out to the internet through old-fashioned modems (you know, the kind that go beep beep beep squark squeek squark ) or USB DSL modems (that no one uses any more, we’re all wireless now. Remember the old green “frog” modem from way back when…?). That has a habit of grabbing a serial port as soon as it appears and trying to configure a modem attached to it. While that’s happening nothing else can access the serial port. It’s especially a problem with boards like the Arduino Leonardno or chipKIT Lenny which create a new serial port when they enter programming mode. So unless you really need the functionality that ModemManager provides you should just remove it:

$ sudo apt-get remove modemmanager "

spycatcher2k:
Find a new PC (A friends) a new USB cable, and retry!

I get the same error on my Win 7 machine.
I've tried another cable (checked it a few hours ago again).

Edit:

kprims:
"$ systemctl status

No serial-getty in sight.

I found the modem service and removed it, but I don't think there lies the problem, because the problem persists on Windows.
But still, one less unnecessary service running.

Tested uploading Blink anyways but I still get the same error.

So, working through that guide revealed that there is something wrong with communications.

When connecting RST and GND as well as TX and RX, I get no feedback from the Serial Monitor from the IDE on two Arduinos (also checked one on Windows).

Well....

anything I can do?

How do you even kill this connection? It worked before uploading one specific sketch. To high of a baud rate? Data throughput while uploading?

I could try and return them (two out of three are broken like this) as I bought them less then a week ago, but one will stay like that as it is older.

Nano clones with Ch340 chips don't work on the regular loop-back test.

Show the sketch that killed them.

Burn the bootloader.

I started hitting this (after the December update?) with my 328p clones.

The two solutions were the old boot loader, as mentioned, and manually halving the speed specified in the avrdude command. Switching to the old boot loader was significantly easier . . .

Try, though, copying the offending line to a terminal and running it from there.

Looks like I've fixed one (will do the rest shortly after).

Here is the solution:

Burn the bootloader (Guide: Burn Bootloader) and connect a capacitor between RST and GND on the working board with the ISP code on it (see this for why: Capacitor for burning Bootloader), in the forum they've used 10uF and 1uF, but 1000uF has worked for me too.

Thank you everyone!