I set mine to 0x9f to enable debug wire for the dragon programmer. The data sheet states that the high fuse should be 0xdf to enable spi programming enable (SPIEN, written 0) else can't load via the spi mechanism. Or would that 12V on the RESET pin override that and allow the HV programmer to do its job (all else being OK)?
AVRDUDE PROGRAMMING THE ATTINY85 SERIAL
Would I be correct in thinking that the RESET pin functionality is required for HV Serial programming? (I believe that it might be possible to recover a larger pin count device using a parallel HV programmer, or perhaps on devices that support JTAG, but those options would not be available on a smaller pin count device.) If the RESET pin functionality of a small pin count AVR device like the ATtiny85 is lost can it be recovered? I still have little knowledge of the AVR. I, naturally, tried to change the values back to their defaults (using the Arduino HV Programmer), but without success. These fuses are reported as having the same values as the other new unit. Writing correct fuse settings to ATtiny.įuses will be read again to check if it's changed successfully. Reading fuse settings from connected ATtiny. I then connected this 2nd new ATtiny85 into the Arduino HV programmer - with the write fuse instructions commented out - and got the following in the Arduino Serial Monitor So I took the other new ATtiny85, hooked it up and ran 'avrdude -p t85 -c usbasp -v' to see how it would respond, and got the same error. Usbasp avrdude: error: program enable: target doesn't answer. My short term memory is not what is once was, so I looked back over my notes and I see that the program upload to the new ATtiny85 (AVRDude and USBASP) failed with a reported error of I have searched for this issue and read quite a bit about related matters but have not yet come across a post that really matches what I have experienced.ĮSD is always a possibility, no matter how careful a person might be. I am sorry if this matter has been addressed elsewhere on this forum. *The 'Arduino HV Programmer' used is based on. I have two questions that those here with their extensive knowledge and experience might be able to answerġ) Has the new ATtiny85 been subject to a stroke? Is its mind still functional, but unable to respond properly to the outside world?Ģ) Is there any way to recover from this? Is there any other programmer and/or technique that might be used to restore the 'normal' functionality of the RESET pin? This Digispark ATtiny85 now responds to the USBASP (e.g. The Arduino HV programmer failed to reprogram the Digispark ATtiny85 fuses initially (many attempts) but eventually managed to write these to their default values. These settings create a number of issues, the most significant probably being a 'reserved' clock select and debugWire enabled. I swapped in the Digispark and the Arduino HV programmer reported the fuses on this device to be L: E1, H: 9D and E: FE I then used an Arduino UNO to create an HV programmer and was able to read the new ATtiny85 device fuses, which were reported as L: 52, H: 5E and E: FE.Īlthough none of these fuse values are the defaults, the High fuse RSTDISBL bit being programmed would be expected to be the problem.īut the *Arduino based High Voltage programmer could not write new fuse values to the device, although it went through the motions. Neither would respond to the Microchip SNAP using MPLABX but I am not going to detail the extensive sequences I went through with that platform. I dug out a Digispark ATtiny85 device, and this also failed after trying to upload the program. This was (is) just a simple 'toggle-pin-after-interval' type program and there was no attempt to modify any fuse settings.īut something went awry and the device would not respond to the USBASP after the upload. I created a basic 'Hello World' (LED blink) program and uploaded using AVRDude and an USBASP. I received a couple of SOIC-8 ATtiny85s recently and, as is my wont, I stuck one of them onto a DIL adapter for testing before I stored them away.