Barebones Arduino Reliability

Hello everyone,

I have an ATMEL ATMEGA328P-PU that I’m successfully loading the bootloader on via an Arduino Uno as ISP. I then move it to a breadboard that’s wired up very simply with my FTDI USB-Serial converter. I’m only working with the Blink sketch at this point (until I can figure this issue out). The issue I’m finding is that I’ll get 1 or 2 successful sketch uploads before (without me touching any wiring) I start getting “programmer is not responding” and “not in sync” errors from avrdude. I have 2 chips behaving in similar ways. The sketch that last successfully loaded continues to run just fine.

If I reload the bootloader (which involves moving the chip to another breadboard) I’ll get another 1-2 sketch uploads before it starts erroring again. Merely pulling the chip out and putting it back doesn’t resolve the issue.

I have a 100pF capacitor wired in series from the DTR pin on the FTDI converter to the reset pin on the 328P and a pull-up resistor also on the reset pin. I’m using the custom board definition for the internal 8MHz clock, if that helps at all.

Let me know if I need to provide any more information.

Here’s the text from avrdude (in the Arduino IDE):

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

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

         Using Port                    : COM5
         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=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x54
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x54

avrdude done.  Thank you.

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

(deleted)

Here’s the output from a successful bootload:

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

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

         Using Port                    : COM6
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         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 : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         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.02s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "<REDACTED_PATH_TO_HEX_FILE>"
avrdude: writing flash (32652 bytes):

Writing | ################################################## | 100% -0.00s

avrdude: 32652 bytes of flash written
avrdude: verifying flash memory against <REDACTED_PATH_TO_HEX_FILE>:
avrdude: load data flash data from input file <REDACTED_PATH_TO_HEX_FILE>:
avrdude: input file <REDACTED_PATH_TO_HEX_FILE> contains 32652 bytes
avrdude: reading on-chip flash data:

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

avrdude: verifying ...
avrdude: 32652 bytes of flash verified
avrdude: reading input file "0x0F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0F:
avrdude: load data lock data from input file 0x0F:
avrdude: input file 0x0F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude done.  Thank you.

The board hex file for the barebones ATMEGA328P is the one listed on the arduino.cc site for this setup here: https://www.arduino.cc/en/uploads/Tutorial/breadboard-1-6-x.zip

Well, as far as the specs are concerned, it shouldn’t work at all, the internal oscillator isn’t good enough for uart without tuning. That’s why even 8mhz official boards use a crystal or resonator.

But I am not satisfied with that explanation, as the clock depends on voltage and temperature, so if it works once under a temperature and voltage, it should always work at that T and V. That reburning bootloader fixes it rules this out

Please POST the boards.txt entry. I’m not going to go dig for it.

Please post the full burn bootloader verbose output, you only posted the second operation, burning bootloader invokes avrdude twice with different arguments

Do you have the decoupling caps? Is vcc and avcc wired right? Post schematic, how you have it wired, not a link to a tutorial, and not drawn with fritzing because we all hate those diagrams here. Hand drawn is fine.

Thanks for responding. My fault on not including both bootloader cycles.

Because it worked the first time, I didn’t bother with decoupling caps. It’s currently being powered through the 5V VCC from the FTDI convertor. Should I throw a 22pF cap between VCC and ground at every entry of VCC into the chip?

VCC, AVCC, and AREF are all hooked up to the +5V rail.

I’ll sketch up a schematic and try to post it this weekend. Thanks for the heads-up about Fritzing. I would have used it for the schematic (not the colorful picture export, but the actual schematic export).

boards.txt (768 Bytes)

Burning_Bootloader.txt (9.03 KB)

For the record, the only reason I'm trying this using the internal 8MHz clock is because I ran out of 22pF caps for decoupling the external 16MHz crystal. But, like you said, if it works once it should continue to work after some fashion.