ATTiny85 won't reprogram

Question

I am using a tiny AVR programmer to program code specifically this one, https://www.amazon.com/dp/B00B6KNJRY?psc=1&ref=ppx_yo2ov_dt_b_product_details , I can successfully upload code onto a blank IC however if I need to make changes or upload a different code to the same IC I get an error avrdude: initialization failed, rc=-1

I'm sorry I am new to this I set the internal clock to 1MHz using the Arduino IDE. How would I set up the fuses such that I am able to to reprogram. If you recommend using a different IDE I can use whatever that is as well

This is what I found inside the package I am using to program using ArduinoIDE ATtinyX5.menu.clock.internal1.bootloader.low_fuses=0x62 ATtinyX5.menu.clock.internal1.bootloader.high_fuses=0xdf ATtinyX5.menu.clock.internal1.bootloader.extended_fuses=0xff

Answer 1

What you listed (0x62, 0xDF, 0xFF) are the factory settings for fuses. There is no need to program them to that values because that's what they should be set to out the box.

Now, assuming that the fuses were for any reason programmed incorrectly, there can be 3 culprits:

• The ATtiny85 has a SPIEN fuse bit which disables SPI programming, but the datasheet lists this bit as inaccessible during SPI programming so this is likely not the issue.
• The more likely possibility - the RSTDISBL bit, which disables the RESET pin. This can be set by standard SPI programming.
• Lastly, if the CKSEL bits are set to use an external clock, which is not present, the chip will be frozen. If you can verify that any code is running after programming, this can easily be ruled out.

If either of these apply, the only way to program the chip is using high-voltage programming (see section 20.6 in the datasheet)

There are also 2 lock bits which can be set by programming, which disable access to the memory. This, however to my knowledge should not disable the programming interface and a chip erase will unlock the chip again.

What you can do is try to flash your program without touching the fuses. This can be done using avrdude directly in command line (-U flash:w:<your_hex_file>:i). There's plenty of tutorials and documentation for this so I won't list the details. If this still causes the issue, it's likely that the chips (or perhaps the programmer) you have are either defective or counterfeit.