ATTiny85-20SU Flashing issues

Other Hardware 3rd Party Boards
1

Hello all!
Im having problems flashing my ATTiny85 chip and I wondered if anyone could help me please?

I have a circuit thats very simple, involving a screen and this surface mount chip. I've bought 100 of them brand new from RS, here in the UK. I've breadboarded the design using a through-hole version of the chip and that all works fine.

I'm using a buspirate v3 and avrdude under Arch linux to do the flashing, with avr-gcc.

Sadly, my surface mount version doesn't work. I've checked all the connections and even tried a second chip. No dice. Here is the output from avrdude

sudo avrdude -c buspirate -p t85 -P /dev/ttyUSB0 -U flash:w:invite.rom -Ulfuse:w:0x42:m -Uhfuse:w:0xdf:m -U efuse:w:0xff:m -F

Attempting to initiate BusPirate binary mode...
avrdude: Paged flash write enabled.
avrdude: initialization failed, rc=-2
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x489bd2
avrdude: Expected signature for ATtiny85 is 1E 93 0B
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.

make: *** [Makefile:5: all] Error 1
[oni@motoko WeddingInvite]$ vim Makefile 
[oni@motoko WeddingInvite]$ make
avr-gcc -I./include/ src/invite.c src/softspi.c src/smallfont.c -Os -o invite.elf -mmcu=attiny85
avr-objcopy -O ihex invite.elf invite.rom
sudo avrdude -c buspirate -p t85 -P /dev/ttyUSB0 -U flash:w:invite.rom -Ulfuse:w:0x62:m -Uhfuse:w:0xdf:m -U efuse:w:0xff:m -F -v

avrdude: Version 6.3, compiled on Feb 21 2016 at 13:33:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : buspirate
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 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     6     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   64    128  4500  4500 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 : BusPirate
         Description     : The Bus Pirate

Attempting to initiate BusPirate binary mode...
BusPirate binmode version: 1
BusPirate SPI version: 1
avrdude: Paged flash write enabled.
AVR Extended Commands not found.
avrdude: initialization failed, rc=-2
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x480bf3
avrdude: Expected signature for ATtiny85 is 1E 93 0B
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
BusPirate is back in the text mode

avrdude done.  Thank you.

What I'm seeing here is the signature is changing each time :confused: This suggests some kind of clock issue right?

My design does not have an external clock - its very simple and I believe that ATTiny85-20SU are set to use a 1MHz internal oscillator by default, which is what I'd like. Can anyone see where I've gone wrong? Do I need to wire in some kind of crystal just for the first flashing?

Cheers

Ben

2

Including -F is never a good choice.

Clocking trouble generally results in 0xFFFFFF or 0x000000. I suspect open connection on MISO.

3

Hello there. Thanks for the reply. Can you elaborate a little on what you mean by an open connection on MISO? As far as I can tell everything is properly connected. Have double and triple checked all connections.

4

The MISO pin on the programmer is not connected to the target (ATtiny85) (or anything else).

5

Thanks. I can confirm it is connected. Pin 6 on the tiny breaks out to the correct pin on the BusPirate

6

Post schematic of the board. Check with multimeter every line of the isp header, checking also for shorts between pins and to vcc/gnd.

7

Sure thing! Here is the schematic and the board itself.

All of the pins are broken out on the chip. I've tried flashing with both the board fully populated and with the just the chip (using the board as a breakout).

I'll triple check the connections to the programmer but given the breadboarded version, I'm pretty sure the connections are good.

8

What on earth are you doing to the reset pin?!

Inadequate decoupling too.

9

cheers!

I notice I've forgotten to put in the 2nd layer traces.

PB5 is the actual reset for the chip. RST on the pins refers to the nokia 5110 screen.

I can see one mistake where pin1 is wired to R2, wheres it should have been pin2 on the chip. This is ok however is R2 is completely optional anyway and can be ignored (and is infact).

Not sure about the decoupling bit?

10

Better image of the board

11

If both R1 and R2 are installed, reset will be connected to the middle of a voltage divider, holding it at a voltage which may or may not trigger a valid reset condition. Your programmer will then try to pull it down further - but most programmers have a resistor in series with their output pins to prevent damage in the event of improper connection, so we may still not be guaranteed of a valid reset condition. If R1 is not installed and R2 is, the LED will prevent the chip from ever leaving reset state (most likely). Either of these would result in a failure to program the chip.

12

Yes I follow

At present, the only thing installed is the chip - U1 / ATTiny. No other components are installed and the full setup will not include R2, just R1 and the LED. This can take place after flashing if needs be. In that configuration, I believe it should work unless there is something else going on. Decoupling or incorrect voltages due to supply or some other factor im not aware of.

13

Install C1, which I assume is your 0.1uf decoupling cap, if it is not present. I've had problems programming '85's without proper decoupling cap in place (in my case, I had a board where I'd simply placed it too far away!)

14

I suspect this could be the problem as the chip itself is not decoupled. I did not require one for the through hole and so believed I did not require one for the surface mount. The screen is decoupled but not the 85. Which pin requires decoupling?

15

I wonder if this is the kind of thing you mean?

16

You need a 0.1uF ceramic capacitor between Vcc and Ground right next to the chip. This is in addition to any decoupling needed for the display, which should be as close to the display pins as possible.

You can dead-bug a through-hole ceramic cap ontop of the chip to test. That's what I did when I had that issue.

17

Thanks for the help! I'll give that a try when I can find the right cap.

18

I had a similar problem a few years ago, see here ATTINY85 : USBasp programming fail "target doesnt answer..." - Microcontrollers - Arduino Forum

19

Hello all. Figured I'd let you know how this ended.

So I tried the decoupling capacitor thing. It makes no difference at all and in all likelihood, isn't needed for such a simple circuit - small fluctuations here and there probably wont matter. The ATTiny seems very forgiving.

Using header pins made a very big different. Soldering them in works a charm. I suspect pogo pins will be something to buy in the near future.

Anyways, despite the flashing I still wasn't getting anywhere. I decided to try a simple blink program and that worked, so clearly the chip was fine.

After scratching my head I replaced the screen with one I took from a sparkfun breakout board. With a little contrast adjustment it worked. My heart sank because I spent a lot on 50 screens from China...

However, on closer inspection, the weird foam connector on the screen looked different between the two screens. It actually comes away in the ones I bought and if flipped over, the screen works like a charm! Not something I expected!

Thanks for all the help! I'll be adding caps and better connections next time around! :slight_smile: