I just got a new batch of ATtiny13A and found that I could not use the "Burn bootloader" function in MicroCore to set the fuses. I was getting chip ID errors from AVRdude.
After checking all the obvious stuff (connections, port, etc.) I tried running AVRdude from the command line and got the same error.
Thinking the chips might have come with a slow clock, I tried various -B values to no avail.
Now here's where it really gets strange:
Via the command line AVRdude could burn a hex file into program memory without any error! And even more strange, once I did that AVRdude was able to burn the fuses!
Once I have burned a sketch manually, everything works fine for that chip. If I pull a new chip out of the sleeve, I have to burn a sketch into it once before it will allow me to set the fuses.
Has anyone else noticed this strange behavior? I'm wondering if there's some sort of timing issue in the version of AVRdude that installs with Arduino?
I'm using a generic ATTiny2313 based USBTinyISP programmer. I have not tried other programmers to see if that has any effect on the problem.
Did your avrdude fuse-setting command include the "erase chip" command?
Depending on where you purchased your ATtiny's, they might have been previously programmed to some non-standard state (lock bits? Strange fuses?)
Can you share (copy and paste here) the error you get when you do "burn bootloader" and copy and paste the avrdude command you used to upload the hexfile?
i am curious what caused this and would like to try if I can reproduce such error in some way.
I'll do a cut/paste when I have time, but it's clear from the error message that the chip ID is being read as all 00's and FF's - not the correct ID for an ATtiny13A. It happens only on a "virgin" chip and only when the -U specifies one of the fuses, but does not happen when -U specifies flash. Once the flash space has been written to, everything works normally.