What is my problem here? The processor or the USB chip?

Using Arduino Installation & Troubleshooting
#1

I would like to post the results of trying to upload the blink sketch to two different Nano’s. One of them works just fine, while the other one fails. And I don’t know what to look at to determine if the problem with the nano that isn’t working, is because the USB chip isn’t working properly, or if there is just something wrong with the ATMega 328 itself.

I’m hoping someone smarter than I am can point out for me the cause of my problem and whether or not I should just trash the nano that isn’t working or can I fix it?

Just to be thorough, note that the only difference between these two upload attempts, is that I try the upload with two different nano’s. The USBASP hardware is the same as is the upload process that I use in terms of the software. I simply upload one, and it works, then I swap the nano with the other one and repeat the process. And yes, if I swap back to the working nano and repeat the process, it works just fine, so I know that the problem is not in the way that I am uploading the sketch and it is not a problem with the USBASP programmer.

Here is the working upload:

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

         System wide configuration file is "C:\Users\michael\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : usbasp
         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 : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD
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: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "C:\Users\michael\AppData\Local\Temp\arduino_build_86533/Blink.ino.hex"
avrdude: writing flash (924 bytes):

Writing | ################################################## | 100% 0.97s

avrdude: 924 bytes of flash written

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:DA, L:FF)

avrdude done.  Thank you.

------------------------------------------
And here is the NON-Working upload:
------------------------------------------

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

         System wide configuration file is "C:\Users\michael\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : usbasp
         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 : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATmega328P is 1E 95 0F
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.

avrdude done.  Thank you.
#2

It is some problem with ATmega328P or its circuits. No response from chip can be caused by:

  1. some problem with wiring connection - I am recommending check the ICSP and appropriate pins on ATmega,
  2. chip is not started - VCC, reset pin must be pulled UP and normally have to have VCC,
  3. reset pulse do not pass,
  4. damaged chip.
    There is another possibility. Chip has been never uploaded/used so it has default 1MHz internal clock set. Chinese USBasp has to be set to slow SCK in such case. There is a jumper on the board, or more probably there are just pads for jumper, which have to be closed for slow SCK. See on Google according your type 'coz sometime it is JP2 and sometimes JP3.
#3

Budvar10:
It is some problem with ATmega328P or its circuits. No response from chip can be caused by:

  1. some problem with wiring connection - I am recommending check the ICSP and appropriate pins on ATmega,
  2. chip is not started - VCC, reset pin must be pulled UP and normally have to have VCC,
  3. reset pulse do not pass,
  4. damaged chip.
    There is another possibility. Chip has been never uploaded/used so it has default 1MHz internal clock set. Chinese USBasp has to be set to slow SCK in such case. There is a jumper on the board, or more probably there are just pads for jumper, which have to be closed for slow SCK. See on Google according your type 'coz sometime it is JP2 and sometimes JP3.

Bud, thank you for your response ... definitely things I did not think about nor did I know to think about ... now I have some questions if you wouldn't mind?

On item 1 ... HOW do I "check the ICSP"?
On item 2 ... "reset pulled UP" - means reset pin must be at 5 volts, right?
On item 3 ... I'm assuming you're referring to the reset signal that would be sent by a DTR pin on a serial port - if one were programming using a serial port that is... ? Do you know how I can check for that working properly? Is it a specific pin I can maybe toss on the scope and look for a trigger read?
On item 4 - if this were the case, why would I be getting all of that information from avrdude before the upload starts? Specifically the statistics on eprom etc. etc.?
Last item ... Of the 5 or 6 Nanos that I have that all are behaving the same way, every single one of them worked at one point ... until they didn't ... so I think your last item might be a non-issue?

Thanks again,

Mike

#4

Reset will use the internal pullup - external pullup is not necessary

Does the chip have a crystal and appropriate loading caps connected? If not, might it have previously been configured to? If the fuses were set to use a crystal (a virgin chip is set to use internal oscillator at 1MHz, a "bootloaded" chip available from some vendors is set up for uno, 16MHz external crystal), but none is connected

Check also for wiring problems (maybe miso shorted low?)

The output with flash/eeprom/etc are from the avrdude configuration file, not from the chip - it hasn't started talking to the chip yet.

The fact that the nano's used to work in the past is a bad sign.

#5

On item 1 ... HOW do I "check the ICSP"?
With DMM (multimeter), ISCP pin versus appropriate pin on the chip. Also it is good to check possible shortage between ICSP pins. Schematics is available here on web.
On item 2 ... "reset pulled UP" - means reset pin must be at 5 volts, right?
Of course, normally RESET pin have to have 5V (if VCC=5V) on powered chip. It should drop to 0V for a while as the upload process start. Should be observable with DMM (pulse generated by avrdude is 200ms).
On item 3 ... I'm assuming you're referring to the reset signal that would be sent by a DTR pin on a serial port...
No. We are discussing ISP. The reset pulse is also essential to start programming.

**On item 4 - if this were the case, why would I be getting all of that information from avrdude before the upload starts? **
This is the answer:
avrdude: error: program enable: target doesn't answer. 1
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000
You can try to run it with detailed log or to run the command from CMD which should be displayed on the top of log with "-vvvv"
param. added and you will see only zeroes in answer. This means that the target is not reachable, either there is no connection to it, or it is not started / powered.

Last item ... Of the 5 or 6 Nanos that I have that all are behaving the same way, every single one of them worked at one point ... until they didn't ... so I think your last item might be a non-issue?
Here I can just repeat @DrAzzy's: It is bad sign. You probably destroyed them. You can try programming via ISP which you already did.

#6