How can I determine if an ATtiny85 is damaged?

Hi,

I followed this tutorial here to be able to program an ATtiny85 with an Arduino nano. I even try it with the 10uF capacitor on the Arduino nano reset pint…

The problem is that, despite having the heartbeat from the Arduino nano, and despite the MOSI signal from it, no positive MISO is ever read from the ATtiny85 as you can see in the picture attached!

How can I determine if an ATtiny85 is damaged?

Thanks

PS: This is the Arduio IDE log and yes, I did the continuity test on the connectors:

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:\Users\Rui\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

         Using Port                    : COM10
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATtiny85
         Chip Erase delay              : 400000 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : possible i/o
         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    12     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   64    128 30000 30000 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    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 = 0x000000 (retrying)

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

avrdude: Device signature = 0x000000 (retrying)

An error occurred while uploading the sketch
Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

Could it have ever been set to use an external crystal or clock source, without one being connected? That will cause it to behave like that.

Also, have you checked continuity of all connections with multimeter, and checked that MISO isn't shorted to ground or something?

Also, WHY DO PEOPLE ALWAYS CUT OFF THE FIRST LINE OF DEBUG OUTPUT THAT INCLUDES THE AVRDUDE COMMAND INVOCATION?! That's the line I'd look at to see if you you were trying to bootload it with a configuration that's probably wrong or something (which would imply that you softbricked the chip first time you tried, leading to the behavior you see now). That line contains more information than the rest of the output most of the time.

DrAzzy:
Also, WHY DO PEOPLE ALWAYS CUT OFF THE FIRST LINE OF DEBUG OUTPUT THAT INCLUDES THE AVRDUDE COMMAND INVOCATION?! That's the line I'd look at to see if you you were trying to bootload it with a configuration that's probably wrong or something (which would imply that you softbricked the chip first time you tried, leading to the behavior you see now). That line contains more information than the rest of the output most of the time.

Here you have it:

Arduino: 1.8.0 (Windows 7), Board: "ATtiny25/45/85, ATtiny85, Internal 8 MHz"

Build options changed, rebuilding all
Sketch uses 684 bytes (8%) of program storage space. Maximum is 8192 bytes.
Global variables use 9 bytes (1%) of dynamic memory, leaving 503 bytes for local variables. Maximum is 512 bytes.
C:\Users\Rui\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/bin/avrdude -CC:\Users\Rui\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf -v -pattiny85 -cstk500v1 -PCOM10 -b19200 -Uflash:w:C:\Users\Rui\AppData\Local\Temp\arduino_build_907521/Blink.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:\Users\Rui\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

         Using Port                    : COM10
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATtiny85
         Chip Erase delay              : 400000 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : possible i/o
         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    12     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   64    128 30000 30000 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    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 = 0x000000 (retrying)

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

avrdude: Device signature = 0x000000 (retrying)

An error occurred while uploading the sketch
Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

Invalid library found in C:\Users\Rui\Documents\Arduino\libraries\Bridge: C:\Users\Rui\Documents\Arduino\libraries\Bridge
Invalid library found in C:\Users\Rui\Documents\Arduino\libraries\Bridge: C:\Users\Rui\Documents\Arduino\libraries\Bridge

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

Hmm, that looks in order.

What settings did you use when you did 'burn bootloader'?

Do you have any other known working t85's you can swap out to verify?

The most common cause of reading the sig as all 0s (other than bad wiring/connections) is having done 'burn bootloader' previously with external crystal or external clock source selected; if you've done that you need to connect such a clock source to it in order to get it to respond - then you can set it to use a different clock source...

DrAzzy:
What settings did you use when you did 'burn bootloader'?

As you can see in the tutorial steps, the "Burn Bootloader" was never used, instead, I just upload the example ArduinoISP in step 3 and got the expected LED Heartbeat blinking...

I just try it a second ATtiny chip with the same results. It's odd that despite all connections pass the continuity test with multimeter the MISO just never goes HIGH! I expected some response from the ATtiny85 to the Nano MOSI...

Heartbeat led tells you nothing. It's driven by the nano.

On a fresh from manufacturer chip, you should have to do "burn bootloader" to get it to run at the specified speed, otherwise it's running at 1mhz instead of 8mhz. Their tutorial has erroneously omitted this necessary step.

Of course, I suspect the "burn bootloader" command will have the same problem.

The tutorial also omits the necessary (critical even) 0.1uf ceramic capacitor between Vcc and Gnd as close to the chip as possible. On breadboard, I would put it across the top of the chip - I've had to trashcan custom manufactured boards because I put the cap too far away and they wouldn't program.

There are some really garbage tutorials around the internet; a lot of them omit the decoupling cap (because sometimes it appears to work, at least for simple cases - other times it doesn't work at all, and sometimes it kinda works but randomly hangs or resets).

DrAzzy:
Also, have you checked continuity of all connections with multimeter, and checked that MISO isn’t shorted to ground or something?

Find it, it was shorted to ground! :smiley: A small black wire I didn’t noticed before.

Now it blinks, the problem is that it takes around 5 seconds instead of 1 second as expected in the Blink sketch!

Thanks

ruiseixas:
Find it, it was shorted to ground! :smiley: A small black wire I didn’t noticed before.

Now it blinks, the problem is that it takes around 5 seconds instead of 1 second as expected in the Blink sketch!

Thanks

No, it takes around 8 seconds :wink:

Because you have not done Burn Bootloader like I said above, so it’s running at 1 mhz, but you’ve told the IDE it’s running at 8mhz, so it calculates the delay based on 8 mhz. But it’s running at 1/8th that speed, so it takes 8 times as long.

Leave all connections the same, tools → burn bootloader, then upload the sketch again, and it will work at the correct speed. You only need to do burn bootloader the first time you use the chip, and when you change the clock speed or clock source.

And, put a 0.1uf cap between Vcc and Gnd, right on the attiny85, before you find a problem caused by not having that and waste time debugging it.