HV (Arduino) Programmer Unable to Set Fuses - ATtiny85

Log in or register to post comments
Go To Last Post
23 posts / 0 new
Author
Message
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
#1
Posted by bWildered1: Thu. Jun 6, 2019 - 03:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

 

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.

I created a basic 'Hello World' (LED blink) program and uploaded using AVRDude and an USBASP.

This was (is) just a simple 'toggle-pin-after-interval' type program and there was no attempt to modify any fuse settings.

 

But something went awry and the device would not respond to the USBASP after the upload.

 

I dug out a Digispark ATtiny85 device, and this also failed after trying to upload the program.

 

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 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.

Although none of these fuse values are the defaults, the High fuse RSTDISBL bit being programmed would be expected to be the problem.

But the *Arduino based High Voltage programmer could not write new fuse values to the device, although it went through the motions.

 

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

These settings create a number of issues, the most significant probably being a 'reserved' clock select and debugWire enabled.

 

The Arduino HV programmer failed to reprogram the Digispark ATtiny85 fuses initially (many attempts) but eventually managed to write these to their default values.

This Digispark ATtiny85 now responds to the USBASP (e.g. avrdude -p t85 -c usbasp -v -B 3)

 

I have two questions that those here with their extensive knowledge and experience might be able to answer

1) Has the new ATtiny85 been subject to a stroke? Is its mind still functional, but unable to respond properly to the outside world?

2) 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?

 

*The 'Arduino HV Programmer' used is based on http://www.electronics-lab.com/r...

 

 

I am sorry if this matter has been addressed elsewhere on this forum. 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.

 

 

Take care

 

Mike

 

 

 

 

This topic has a solution.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, solved
Last Edited: Sun. Jun 9, 2019 - 10:50 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101574 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jun 7, 2019 - 09:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bWildered1 wrote:
Has the new ATtiny85 been subject to a stroke?
What you describe sounds more like "locked in syndrome" ;-)

 

Anyway I am not aware of anything you can do to an AVR to prevent HV being used to recover. So if you are really saying that the chips cannot be corrected with HV either your HV programmer is wrong or the chips are seriously FUBAR. Could they have suffered ESD damage or reverse/over voltage or something?

Last Edited: Fri. Jun 7, 2019 - 09:29 AM
Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Fri. Jun 7, 2019 - 05:34 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson

Keeping well, I trust.

 

Reverse voltage, no.

ESD is always a possibility, no matter how careful a person might be.

 

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

 usbasp avrdude: error: program enable: target doesn't answer. 1

 avrdude: initialization failed, rc=-1

 

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.

 

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

Reading signature from connected ATtiny......

Reading complete..

Signature is: 930B

Reading fuse settings from connected ATtiny.......

LFuse: 52, HFuse: 5E, EFuse: FE

Reading complete..

The ATtiny is detected as

ATTINY85..

Writing correct fuse settings to ATtiny.......

Writing complete..

Writing correct fuse settings to ATtiny.......

Writing complete..

Writing correct fuse settings to ATtiny.......

Writing complete..

Fuses will be read again to check if it's changed successfully..

Reading fuse settings from connected ATtiny.......

LFuse: 52, HFuse: 5E, EFuse: FE

Reading complete..

 

These fuses are reported as having the same values as the other new unit.

I, naturally, tried to change the values back to their defaults (using the Arduino HV Programmer), but without success.

 

I still have little knowledge of the AVR.

I suppose the primary question is...

If the RESET pin functionality of a small pin count AVR device like the ATtiny85 is lost can it be recovered?

(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.)

 

Would I be correct in thinking that the RESET pin functionality is required for HV Serial programming?

Or would that 12V on the RESET pin override that and allow the HV programmer to do its job (all else being OK)?

 

Thank you for the response.

 

Take care

 

Mike

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4839 View posts
Location: SF Bay area
Posted by westfw: Fri. Jun 7, 2019 - 10:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would I be correct in thinking that the RESET pin functionality is required for HV Serial programming?

Or would that 12V on the RESET pin override that and allow the HV programmer to do its job (all else being OK)?

In theory, 12V on RESET works to put the device into "HV Serial Programming Mode" even if the fuse has reset disabled.

 

 

I then used an Arduino UNO to create an HV programmer

 Note, however, that on most of the older ATtiny chips, you can't simply replace a functioning RESET with 12V on RESET.  HVSP is different than ISP programming, and uses more pins ("why?" is an interesting question.)

When you're using the Uno to drive the HVSP, do you have ALL of the needed connections made?   In particular, I think "command" and "data" are on separate pins, and I can at least imagine a scenario where you can talk to the chip with commands, but need the data pin in the right state to actually change the fuses...

 

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
This reply has been marked as the solution. 
Posted by jkwilborn: Sat. Jun 8, 2019 - 03:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.  I set mine to 0x9f to enable debug wire for the dragon programmer.  The data sheet also states that an HVSP programmer is required once RSTDISBL (or DWEN) fuse has been written to a zero (enabled.)  Keep in mind that these particular fuses are written a zero to enable the function.

 

I've deal with these devices for a number of years and I've found the 99% of the time, when they don't do what you want, it's not configured properly for the intended function.

 

You might look at the memory lock bits as they can hose you up also.  "Lock bits can be erased to “1” with the Chip Erase command, only" says Atmel... Have you tried to do an erase operation with avrdude?

 

Your statement "The Arduino HV programmer failed to reprogram the Digispark ATtiny85 fuses initially (many attempts) but eventually managed to write these to their default values." leads me to believe that you may have a timing issue with the programmer/software.  Maybe a timing problem that occurs during the HVSP operation?  Hardware generally doesn't work now and then, maybe the timing is on the edge?   Other option is finding someone with a known good programmer.

 

I have severely abused these guys along with having bricked many of the tiny series and more mega328's than I can remember, but the dragon and the hv parallel or serial programming mode always brings them back to life. I've never lost one.

 

I put a new tiny85 in my dragon and the following is an interactive (-t, terminal mode) invocation of avrdude and the results...

 

$> avrdude -pt85 -cdragon_isp -Pusb -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude> d hfuse 0 1
>>> d hfuse 0 1
0000  df                                                |.               |

avrdude> d lfuse 0 1
>>> d lfuse 0 1
0000  62                                                |b               |

avrdude> d efuse 0 1
>>> d efuse 0 1
0000  ff                                                |.               |

avrdude>

So the three fuses are HF: 0xdf, LF:0x62 and EF 0xff, brand new chip from Mouser...  If you can get it to me, I'll take a shot at resurrection... :)

 

Good luck... Keep in touch..

 

Jack :)

 

 

 

Last Edited: Sat. Jun 8, 2019 - 03:38 AM
Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sat. Jun 8, 2019 - 11:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


westfw wrote:

In theory, 12V on RESET works to put the device into "HV Serial Programming Mode" even if the fuse has reset disabled.

OK.

It should therefore be possible to use High Voltage Serial Programming (HVSP) to recover a device that has had RESET disabled.

 

I used the following to connect the ATtiny85 to the Arduino HVSP

 

from http://www.electronics-lab.com/r...

 

 

In short, MOSI, MISO, SCK, CLKI and a switched 12V on RESET. The VCC/VDD supply is also controlled via an Arduino GPIO.

 

I need to think a bit.

 

Thank you westfw

 

Take care

 

Mike

Top
Brian Fairchild
Brian Fairchild's picture
Level: Raving Lunatic
Joined: Thu. Oct 18, 2001
Posts: 5432 View posts
Location: Eastern England.
Posted by Brian Fairchild: Sat. Jun 8, 2019 - 11:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the 12V is on the reset pin UNLESS pin 13 is high?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 12:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The tiny85 is an 8 pin package... Pin 13?

Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sat. Jun 8, 2019 - 12:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

So the 12V is on the reset pin UNLESS pin 13 is high?

 

Yes...

 

An extract from the Arduino HV Programmer sketch...

 void setup() {
  pinMode(VCC, OUTPUT);
  pinMode(RST, OUTPUT);
  pinMode(SDI, OUTPUT);
  pinMode(SII, OUTPUT);
  pinMode(SCI, OUTPUT);
  pinMode(SDO, OUTPUT); // Configured as input when in programming mode
  digitalWrite(RST, HIGH); // Level shifter is inverting, this shuts off 12V 

  ...

void loop() {
  if (Serial.available() > 0) {
    Serial.read();
    pinMode(SDO, OUTPUT); // Set SDO to output
    digitalWrite(SDI, LOW);
    digitalWrite(SII, LOW);
    digitalWrite(SDO, LOW);
    digitalWrite(RST, HIGH); // 12v Off
    digitalWrite(VCC, HIGH); // Vcc On
    delayMicroseconds(20);
    digitalWrite(RST, LOW); // 12v On

 

 

Take care

 

Mike

 

 

Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sat. Jun 8, 2019 - 12:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jkwilborn wrote:

The tiny85 is an 8 pin package... Pin 13?

 

Arduino UNO (ATmega328P based) pin 13.

 

 

Take care

 

Mike

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 12:50 PM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry about that... Didn't realize you were talking about the programmer...  I need to look at the ATMEL docs on how the exact process works myself.  Having a dragon, I don't worry about it much.

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 01:25 PM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know the HVSP works when RSTDISBL or DWEN are enabled, since I use port b pin 5 (reset pin) as output, so it's reset function is disabled on some projects.  To modify the software I have to reload the flash and I have to use hvsp as the normal reset is disabled, making a load via isp impossible.  Did you load the offending program (that bricked your devices) via USB on the Digispark board or your programmer on a breadboard?  Can you post the offending source program?  Along with the command line? That may help us determine what's happening.  So did you brick the Digispark board or another t85?

 

It's still curious that it will program (the correct bits in the fuses, yes?) but not consistently?  If it will reset (to a 1) either of the RSTDISBL or DWEN bits then it must be working.  If you can change other bits, but not those, then maybe not...

 

I think we need to be more detailed here if you want some success with this....  For instance, what is your hardware setup?  Is the device only powered by the programmer (in your case the Arduino)?  What value are you attempting to set for these fuses?  Something smells if you can get 'partial' success with this.  Only the two RSTDISBL & DWEN, require the HVSP, as far as I can remember. The lock bits are also important.  Have you explicitly told avrdude to 'erase' the target?  If not, this will not correct the lock bits if they are the issue. The '-e' option of avrdude does the chip erase. Or type 'erase' when in avrdude interactive mode.  Have you tried interactive mode? Is this in a bread board on in existing circuitry?  Have you modified any of the programmers attributes, such as the clock?

 

Did you use the same components as was called out in the design of the programmer, like the switching transistor, a generic 2n2222 or did you substitute?  Did you modify any of the code on the programmer?  I guess the programmer documentation (source) tells you it's high to turn off the 12v.  I'm kind of wondering if you are getting the 12v to the reset pin.  Do you have any way of determining if the 12v is getting there at the proper time for the proper length during the burn or any of the above? What are you using for power supplies, like where is the 12v coming from? Common ground...so forth...?

 

Rest assured that the HVSP is able to recover a bricked device.  With a HVSP, the RSTDISBL bit doesn't matter but the sequence of the application of power and programming must occur in the proper time frame.  I don't think it's just the 12v on reset that allows the operation.  Do you have the link to the ATMEL docs on HVSP sequence.  I can't seem to locate it and I need to brush up on the sequence.  I'll continue to hunt for it...

 

As a general rule with these things a code fragment is usually not enough to determine much.  I did look at the arduino programmer software real quick, but it probably works ok unless you've dabbled with it.  You didn't did you?...  I'm shooting at anything at this point, so hang in there with us and don't be offended since we're both clueless about each others technical levels..

 

I'm sure it's fixable, we're just missing something... It'll probably turn out to be something simple and we've totally obfuscated the issue. 

 

Keep us informed, we'll do all we can to help...  Good luck

 

Jack :)

 

 

 

Last Edited: Sat. Jun 8, 2019 - 02:00 PM
Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 02:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did find this from Microchip (guess we should start with their new name...)

 

Fuse settings that disable the ISP programming interface and most likely brick the device.

 

Still haven't located the exact steps from them on the HVSP process.

 

Jack :)

 

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 03:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noticed the Microchip stated that the jtag could be used to modify these bits.  I have never used the jtag on a microchip device but have on other manufacturers.  You may have some of this hardware now, it does have some issues, read the article.

 

Tiny AVR JTAG Programmer

 

Jack :)

 

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101574 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sat. Jun 8, 2019 - 03:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No tiny has JTAG

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 04:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At least the 8 pin devices don't seem to support it...  I know I've use it on avr devices, but can't remember which....  Saw on one of the docs that you can use jtag to set those fuses.  I though I read it in something related to the tiny series, but wouldn't be the first time I hosed something up, probably not the last...

 

Thanks :)

 

Last Edited: Sat. Jun 8, 2019 - 04:26 PM
Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sat. Jun 8, 2019 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Jack, thou art gifted.

 

As I write this, one of the new ATtiny85 devices is winking away at me with a certain nonchalance.

 

But first, I'll dispose with the side issues.

 

jkwilborn wrote:

Your statement "The Arduino HV programmer failed to reprogram the Digispark ATtiny85 fuses initially (many attempts) but eventually managed to write these to their default values." leads me to believe that you may have a timing issue with the programmer/software.  Maybe a timing problem that occurs during the HVSP operation?  Hardware generally doesn't work now and then, maybe the timing is on the edge?   Other option is finding someone with a known good programmer.

 

I have a half suspicion that this might be related to the capacitors across the power lines of the Digispark ATtiny85 affecting the rise time of the power supply to the chip, a suspicion that I am not going to follow up at this time.

 

I have described the programmer I have used to try to reprogram the fuses as an Arduino High Voltage programmer, but this is not strictly correct. It would be more accurate to describe this as an Arduino High Voltage Fuse Programmer, as this does not attempt any other programming currently.

 

jkwilborn wrote:

You might look at the memory lock bits as they can hose you up also.  "Lock bits can be erased to “1” with the Chip Erase command, only" says Atmel... Have you tried to

do an erase operation with avrdude?

 

As the only mechanism I have that can read or (possibly) write to these devices is the Arduino HV Fuse Programmer (neither the USBASP nor the SNAP can communicate with the affected ATtinys), I modified the Arduino sketch to add a HV chip erase capability, and added user entry fuse write and chip erase options

 void chip_erase () {

    Serial.println("Erasing Flash and Lock Bits...");

    shiftOut(0x80, 0x4C);
    shiftOut(0x00, 0x64);
    shiftOut(0x00, 0x6C);

    while (!digitalRead(SDO));   //wait until chip erase completes (wait until SDO goes high)

 }

 void setup() {

  ...

  Serial.println("Enter 'w' to write fuses to defaults...");

  Serial.println("Enter 'e' to erase flash and lock bits...");
 }

void loop() {  

   ...

   else if (sig == ATTINY24 || sig == ATTINY44 || sig == ATTINY84 || \
      sig == ATTINY25 || sig == ATTINY45 || sig == ATTINY85) {

      Serial.println("The ATtiny is detected as ");
        if(sig == ATTINY24) Serial.println("ATTINY24..");
        else if(sig == ATTINY44) Serial.println("ATTINY44..");
        else if(sig == ATTINY84) Serial.println("ATTINY84..");
        else if(sig == ATTINY25) Serial.println("ATTINY25..");
        else if(sig == ATTINY45) Serial.println("ATTINY45..");
        else if(sig == ATTINY85) Serial.println("ATTINY85..");

        if (inst == 'w')  {
          Serial.println("Writing fuses to default values...");
          writeFuse(LFUSE, 0x62);
          writeFuse(HFUSE, 0xDF);
          writeFuse(EFUSE, 0xFF);
        }
        else if (inst == 'e') {
          Serial.println("Erasing flash and lock bits...");
          chip_erase();
        }
    }

I erased one of the new ATtiny85 devices (using the Arduino HV fuse programmer).

 

Reading signature from connected ATtiny......
Reading complete..
Signature is: 930B
Reading fuse settings from connected ATtiny.......
LFuse: 52, HFuse: 5E, EFuse: FE
Reading complete..
The ATtiny is detected as
ATTINY85..
Fuses will be read again to check if it's changed successfully..
Reading fuse settings from connected ATtiny.......
LFuse: 52, HFuse: 5E, EFuse: FE
Reading complete..

Reading signature from connected ATtiny......
Reading complete..
Signature is: 930B
Reading fuse settings from connected ATtiny.......
LFuse: 52, HFuse: 5E, EFuse: FE
Reading complete..
The ATtiny is detected as
ATTINY85..
Erasing flash and lock bits...
Erasing Flash and Lock Bits...
Fuses will be read again to check if it's changed successfully..
Reading fuse settings from connected ATtiny.......
LFuse: 52, HFuse: 5E, EFuse: FE
Reading complete..

 

I was then able to successfully rewrite the fuses to their defaults.

 

Reading signature from connected ATtiny......
Reading complete..
Signature is: 930B
Reading fuse settings from connected ATtiny.......
LFuse: 52, HFuse: 5E, EFuse: FE
Reading complete..
The ATtiny is detected as
ATTINY85..
Writing fuses to default values...
Writing correct fuse settings to ATtiny.......
Writing complete..
Writing correct fuse settings to ATtiny.......
Writing complete..
Writing correct fuse settings to ATtiny.......
Writing complete..
Fuses will be read again to check if it's changed successfully..
Reading fuse settings from connected ATtiny.......
LFuse: 62, HFuse: DF, EFuse: FF
Reading complete..

I successfully 'recovered' the other errant ATtiny85 as well.

 

I then programmed one of the new ATtiny85s with a simple LED blink program, and tested. All is well.

 

Jack, altough I was not able to read the lock bits, your suggestion that the problem might be due to the lock bits would seem to be correct.

 

And so this matter is now resolved.

 

To answer other questions posed, for the sake of completeness...

The devices 'bricked' were the two new ATtiny85s. These devices would seem to have arrived in a 'bricked' state.

The Digispark ATtiny85 was (is) a device I have had for some time, and was known to be working before this. But the reason it appeared to be not working is my fault. I had - when testing out a then newly received SNAP programmer/debugger with MPLABX - configured this Digispark to use debugWire. (Yea, I know, silly me!). So that device was really working all the time; it just could not be programmed with the USBASP.

The transistor I used with the HV Fuse programmer was (is) a BC337

The 12V was supplied by a SEPIC (Buck-Boost) converter - itself supplied by a mains 'power brick' - and the voltage measured at 11.86V (I had also added a 1500uF capacitor across the 12V supply to the ATtiny85.)

I checked back through my notes and the very first AVRDude command, and response, to the new ATtiny85 device was

 

avrdude -p t85 -c usbasp -e -U flash:w:ATtiny85BlinkTimer.hex -B 3
	usbasp avrdude: error: program enable: target doesn't answer. 1
	avrdude: initialization failed, rc=-1

The 'ATtiny85 blink' program code is

#include <avr/io.h>
#include <stdint.h>

int main(void)
{

    DDRB = 0x01;    //PB0 output
    //timer0 is 8 bit
    TCCR0A = (1<<COM0A0 | 1<<WGM01);    //toggle 0C0A, CTC mode
    TCCR0B = 0x05;                      //clock/1024
    OCR0A = 244;                        //1/2 second (4Hz)

    while(1)
    ;

    return 0;
}

 

I do have another question that leads out of this...

ATtiny85 High Voltage Programming Instructions

 

The instruction headings are 'Instr.1/5', 'Instr.2/6', 'Instr.3', 'Instr.4'

This would suggest 'Instruction 1 and 5', 'Instruction 2 and 6', 'Instruction 3' and 'Instruction 4'

But the 'Operation Remarks' section to the right indicates that after 'Instr3' the chip erase will complete when SDO goes high.

Therefore there is no need for 'Instr.4' (of which there is none anyway), 'Instr.5' or 'Instr.6'.

 

This is perhaps more pertinent to the fuse write operations...

 

 

An idiot like me would suppose that - to write to the fuses - Instr.1 is followed by 'instr.2', then 'Instr.3', 'Instr.4', 'Instr.5' and finally 'Instr.6'.

The 'Operation Remarks' section would suggest the process ends after 'Instr.4'.

 

Am I being particularly dense?

 

I would not want to miss something simple that could trash my lovely little micros.

 

 

Thank you Jack, and all others, for your help with this.

The two 'locked-in syndrome' (clawson) ATtiny85 devices are now fully functional.

 

I would not have resolved this matter without you.

 

Take care

 

Mike

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 08:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems odd that you got 'new' chips that are not programmable with the normal isp interface, and in your case pre-bricked:)

 

Many op codes have variable number of parameters.  For instance an 'immediate load', might only be two bytes in object code (machine code,) first is the op code or instruction followed by the byte (or 'immediate' data).  But storing an immediate byte in upper memory requires the address (upper and lower bytes) to be loaded in a register that can address that space and then store the byte, so in most cases it's  more then two bytes in the object code.  This is especially true with non RISC processors. Most of the tiny's op codes are two bytes and it is a RISC.

 

If you look down further I think you'll find that other operations require more bytes or information for it to 'complete'... 

 

Read Flash Low and High Bytes requires all six bytes

 

Does this make sense?

 

Anyway, I'm glad you got it fixed, have fun and pass on your knowledge.

 

Jack :)

 

P.S.  Did you revive the DIgispark tiny85 also?

 

Last Edited: Sat. Jun 8, 2019 - 08:41 PM
Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sat. Jun 8, 2019 - 08:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jkwilborn wrote:

Many op codes have variable number of parameters.  For instance an 'immediate load', might only be two bytes in object code (machine code,) first is the op code or instruction followed by the byte (or 'immediate' data) that needs to be dealt with.  But storing a byte in upper memory requires the address (upper and lower bytes) to be loaded in a register that can address that space and then store the byte, so it it more then two bytes in the object code.

 

If you look down further I think you'll find that other operations require more bytes or information for the 'operation to complete'... 

 

Read Flash Low and High Bytes requires all six bytes

 

Does this make sense?

 

Anyway, I'm glad you got it fixed, have fun and pass on your knowledge.

 

Jack :)

 

Thank you.

 

And thank you for all your help.

 

Yes, that does answer my question.

But it leads to another.

 

When referring to those tables for HV Serial Programming, is there any single place where the number of instructions required is listed?

In short, for an idiot like me, it would have been nice to have an extra column that stated 'Number of Instructions' for the chip erase process as being 3.

And so on.

 

Or does this information have to be inferred from the other information supplied?

 

Thank you again Jack.

 

Do take care.

 

Mike

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sat. Jun 8, 2019 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds good, all of it at one place.  I think the manual is as close as it comes.  I think that's an impossibility with these devices.

 

You can figure cycles from this Table 20-12 (I think we have the same manual.) Which tells you how many bytes for each instruction, you still have to count them...

 

Chip Erase (Program Memory/EEPROM)  $AC  $80

 

Looks like two bytes to me... Are you including something else?

 

Anyway, hope I've helped and not made it worse..

Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sun. Jun 9, 2019 - 09:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


jkwilborn wrote:

Sounds good, all of it at one place.  I think the manual is as close as it comes.  I think that's an impossibility with these devices.

 

You can figure cycles from this Table 20-12 (I think we have the same manual.) Which tells you how many bytes for each instruction, you still have to count them...

 

Chip Erase (Program Memory/EEPROM)  $AC  $80

 

Looks like two bytes to me... Are you including something else?

 

Anyway, hope I've helped and not made it worse..

 

Ah *^%^&!

 

Hmmm!

 

Table 20-12 shows me this

 

while Table 20-16 shows

The latter suggests

SDI 0x80, 0x00, 0x00 with

SII  0x4C, 0x64, 0x6C

 

a sequence of three instructions.

 

Do you know, I'm sorta sorry I asked.

Never mind! Just put this down to me being too curious.

I'll go away now.

 

Many thanks for all your help.

I would not have got as far as I have without you all.

 

Take care

 

Mike

Top
bWildered1
bWildered1's picture
Level: Rookie
Joined: Wed. Apr 10, 2019
Posts: 24 View posts
Posted by bWildered1: Sun. Jun 9, 2019 - 09:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bWildered1 wrote:

jkwilborn wrote:

Sounds good, all of it at one place.  I think the manual is as close as it comes.  I think that's an impossibility with these devices.

 

You can figure cycles from this Table 20-12 (I think we have the same manual.) Which tells you how many bytes for each instruction, you still have to count them...

 

Chip Erase (Program Memory/EEPROM)  $AC  $80

 

Looks like two bytes to me... Are you including something else?

 

Anyway, hope I've helped and not made it worse..

 

Ah *^%^&!

 

Hmmm!

 

Table 20-12 shows me this

 

while Table 20-16 shows

The latter suggests

SDI 0x80, 0x00, 0x00 with

SII  0x4C, 0x64, 0x6C

 

a sequence of three instructions.

 

Do you know, I'm sorta sorry I asked.

Never mind! Just put this down to me being too curious.

I'll go away now.

 

Many thanks for all your help.

I would not have got as far as I have without you all.

 

Take care

 

Mike

 

Oops!

 

Table 20-12 is labelled Serial Programming Instruction Set while Table 20-16 is High-voltage Serial Programming Instruction Set...

 

I do need to keep my silly questions to myself.

 

Take care all.

 

Mike

Top
jkwilborn
jkwilborn's picture
Level: New Member
Joined: Tue. Oct 11, 2016
Posts: 14 View posts
Posted by jkwilborn: Sun. Jun 9, 2019 - 05:08 PM (Reply to #21)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike, don't ever feel guilty for being curious.  I understand.  I have not programmed anything to handle the serial controls, so you have more experience than I do...  Since you made it work, I can only say 'cool'...  I'm sure we're missing something here.  I don't have time to chase down all the things I'd like to know and this is really one of them.

 

Thinking about the tiny85's you received,  I have some suspicions..  The factory doesn't lock them, those bits are only used to keep intellectual data safe.  In other words, to lock the device so the software cannot be extracted.  Most people don't have hvsp devices available or many are clueless about building the proper hardware.  It's nice to see others doing this.  This leads me to believe that the devices were programmed for some other purpose and the code was wrong or they didn't use all the devices in a production run.  Meaning they could be picked up cheap... and resold ?  They apparently work, if you have the right expertise to resurrect them...  I wonder how many people felt ripped off when they couldn't work...  Just curious, where did you get them? If you don't mind me asking?  Hope you got a good deal :)

 

Take care, keep up the curiosity...

 

Jack (8O

 

Top