Attiny 13A burning bootloader

Hello,

I wish to burn the Arduino Boatload on an Attiny13a.

I have set up an Arduino Uno with the "Arduino ISP" sketch. I have wired the UNO to the Attiny13 as I am supposed to, power, gnd, miso+mosi+sck+reset - as seen on the internet (tm). I have put a 10uf cap between reset and gnd on the uno.

So, I have tried three things: Download the attiny13 from Boards-manager, download two separate libraries ( Smeezekitty core and Damellis’es ATtiny cores). Depending on the library, i set up the boards.txt file to include the boards i need.

After this, i choose the Attiny13 in the menu, set usb, "arduino isp" as programmer - and click "burn bootloader".

I get input like this:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude: Device signature = 0x1e9007
avrdude: erasing chip
avrdude: reading input file "0xff"
avrdude: writing lock (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.23s

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

Error while burning bootloader.
Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x3f != 0xff
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Now, something is wrong. But i am completely lost at where to begin. I have the latest version of Arduino - and im on a mac.

On an addition note, if I try to use Burn Bootloader, via an USBASP, I also get the same error:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0xff
avrdude: verification error; content mismatch

boards.txt entry and/or avrdude.conf entry are incorrect.

My guess is copy-paste errors from copy/pasting entries from other parts.

Actually, looking at the datasheet, I'm pretty sure both the boards.txt and avrdude.conf entries must be bad to generate the first error...

The second error is not the same as the first. 0x00 and 0x3F are not the same. You have also clipped off key information from the second error - the lines before what you posted tell you what memory it was trying to verify.

You DO understand that there is no actual bootloader for the ATtiny13, right? It's only got 1k of flash, and about the most bootloaders are about 512 bytes... The "burn bootloader" command for the tiny chips that don't have an actual bootloader is used to set the fuses to a known state...

westfw:
You DO understand that there is no actual bootloader for the ATtiny13, right? It’s only got 1k of flash, and about the most bootloaders are about 512 bytes… The “burn bootloader” command for the tiny chips that don’t have an actual bootloader is used to set the fuses to a known state…

True. But it does burn the fuses

I am guessing that she(?) has a wiring error on the ISP pins or perhaps the wires are too long. Then again I just noticed the age of his thread

Wiring problems usually fail earlier.

Errors like that can be reproduced readily with improper our mismatched boards.txt and/or avrdude.conf entries (I’ve encounter them many times working on my core)

DrAzzy: Wiring problems usually fail earlier.

Errors like that can be reproduced readily with improper our mismatched boards.txt and/or avrdude.conf entries (I've encounter them many times working on my core)

I have definitely seen wiring problems cause verification errors. Another common cause for it is if you don't connect the grounds. That can be a pain to troubleshoot because sometimes it will program all the way and other times it will stop at some random point in the process

westfw:
You DO understand that there is no actual bootloader for the ATtiny13, right?

maybe not in arduino land but there are a couple out there. even besides the ones i have written myself. i think “pico” written by the aspergers guy on freaks was ported.

very few reasons to do one but sometimes no choice considering number of pins available. i know mine use only one pin (no reset). it was a bear getting down to 32 bytes which is minimum block boundary. below that one must forgo standard rs232 format but still possible.