Setting fuses - macOS and a Mega

Hi there guys,

I need a bit of a help from you.
Surely, I'm not an everyday Arduino user, but I'm already after a lot of reading and searching :sa:

I have a code, that should run on an Attiny85.
I've programmed my Mega to use it as a programmer.
Also, I've wired up the chip and the Mega on a breadboard.

I was able to burn the bootloader and the code to the chip trough Arduino IDE with the Mega to the chip.
Now, the original creator of the code told me that I have to change the fuses, but I should do this after programming the chip, since it'll change / sacrifice pin1 on the Attiny.

I've tried to make AVRFuses to work, without success ...

Could you please tell me guys how can I do this on macOS, also, I'd like to use my Mega for this, since I'm not sure I have the proper programmers for the task :S

if you

then fuses are set.

do you mean Arduino Mega2560 R3 board?

Hi there,

Yapp, bootloader is done fuses are OK, but for this particular code, I have to change the fuses.
Specially on pin 1, since that pin is used to do something else.

From terminal, with avrdude, I was able to do something, yet, I think I've bricked the chip with bad fuse settings, since now it is fully dead.

I've asked the guy who made the code, I've been told that I should put the values to a fuse calculator in the order how they are in the code:

Fuses: 0xE1 0xDF 0xFF

Then the calculator will tell me the code bits, which is now looks like this:

avrdude -p attiny85 -cstk500v1 -P /dev/cu.usbmodem211101 -b 19200 -e -U lfuse:w:0xE1:m -U hfuse:w:0xDF:m -U efuse:w:0xFF:m -U lock:w:0xFF:m

I'm still not sure about the lock bit, but I really do not want to brick another chip :S

Disclaimer: this is mostly outside my area of expertise.

Usually one will be able to read back the fuses as long as the chip is correctly clocked. E.g. -U efuse:w:0xFF:m will write the extended fuse and -U efuse:r will read it.

You can recover the chip with a high-voltage programmer.

Do you remember what you did?

How do you know?

The hfuse controls the RSTDISBL bit. With the above command you did not change it.

This is a simple oscillator chip.
pin 1 reads 0-5V, without the dang fuse settings, it does only the same pitch.
I'm suspicious that the chip that I've tried to set the fuses is dead, since it doesn't make anything in my circuit...

Yapp, I save all the terminal codes I use since I'm totally noob :smiley:
I've used this and after this, the chip is kinda gone.

avrdude -V -p attiny85 -c cstk500v2 -P /dev/cu.usbmodem211101 -B 10 -e -u
-U efuse:w:0xff:m
-U hfuse:w:0xdf:m
-U lfuse:w:0xe1:m \

I still have like 4-5 chips, but you know, I really do not want to trash them all with my bloody trial and error thing.
I have a working circuit for this chip, but what I got from the original developer is basically the code (ino file).

I have btw a working chip, I wonder if I can read the fuse settings from that somehow, just to see if I've been told the correct ones :S

Tried to set the fuses back to defaults.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: erasing chip
avrdude: reading input file "0x6A"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x6A:

Reading | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:

Reading | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFF:

Reading | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xFF"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xFF:

Reading | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock verified

avrdude done.  Thank you.

The '-e' causes an erase of the flash, eeprom and lock bits so your code is gone. When setting the fuse bytes, I think that you should not use '-e'.

See AVRDUDE: 2.1 Option Descriptions

O man - I hate when I'm dumm.
Anyway, I can't really do anything with this particular chip now - can't burn bootloader, can't upload the code again...

tried to read out the fuses on the bad chip with the following command

avrdude -p attiny85 -cstk500v1 -P /dev/cu.usbmodem211101 -b 19200 -U lfuse:r:-:i -v

and the results are troubling:

avrdude: Version 7.0
         Copyright (c) Brian Dean, http://www.bdmicro.com/
         Copyright (c) Joerg Wunsch

         System wide configuration file is "/opt/homebrew/etc/avrdude.conf"
         User configuration file is "/Users/encoder/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem211101
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 us
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom                 65     6     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash                  65     6    32    0 yes      8192   64    128  4500  4500 0xff 0xff
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

Tried to read out the one and only working chip, programmed bythe code designer himself.

avrdude -p attiny85 -cstk500v1 -P /dev/cu.usbmodem211101 -b 19200 -U lfuse:r:-:i -U hfuse:r:-:i -U efuse:r:-:i -v -F


avrdude: Version 7.0
         Copyright (c) Brian Dean, http://www.bdmicro.com/
         Copyright (c) Joerg Wunsch

         System wide configuration file is "/opt/homebrew/etc/avrdude.conf"
         User configuration file is "/Users/encoder/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem211101
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 us
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom                 65     6     4    0 no        512    4      0  4000  4500 0xff 0xff
           flash                  65     6    32    0 yes      8192   64    128  4500  4500 0xff 0xff
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000707
avrdude: Expected signature for ATtiny85 is 1E 93 0B
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "<stdout>"
:01000000FF00
:00000001FF
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "<stdout>"
:01000000FF00
:00000001FF
avrdude: reading efuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "<stdout>"
:01000000FF00
:00000001FF

avrdude done.  Thank you.

did not get smarter :smiley:

I unfortunately can't help you further except for by guessing. Maybe @DrAzzy has some ideas (hope he doesn't mind calling has name).

I'd appreciate any kind of help for sure.
It seems that the chip is working correctly, except for pin 1.
The code designer told me that after burning the bootloader and programming the blank chip, I should set up the fuses, but I should be careful, since once I've set up the fuses, I can't go back.

So I've programmed all the chips I have (I need at least 5 of them - 1 is gone now...) and now I just have to figure out how to set the fuses.

The guy told me, I should just put them in the fuse calculator and it'll drop me the code...
Pin it does not touches pin1 for sure :S

nonsence. there exist no "do-the-chip-brick" fuse.


nothing dangerous is in this fuses. they set start time, clock source and enable SPI.

Ah I see...
Then why is the chip "invisible" to literally anything?
Can't program it, can't read it, does nothing...
Even if it is empty now, I should be able to reprogram it, right?

are you using "Arduino As ISP" with Arduino Mega board? i want not think that the chip is poor quality and dying on any try to reprogram it.

Yapp, a Mega as ISP.
Finally, turned out (meh...) that I had the wrong info.
With this code, I was able to set the fuses correctly on the other 4 chips, the are OK now.
Luckily, I've documented all the terminal commands I had :smiley:

avrdude -p attiny85 -cstk500v1 -P /dev/cu.usbmodem211101 -b 19200 -U lfuse:w:0xE1:m -U hfuse:w:0x5F:m -U efuse:w:0xFF:m

My tip is that I've set fuses for the first chip wrongly, so it is now either running on wrong clock or something like this.
It does nothing and when I try to re-program it, it either says can't connect or something with incorrect device ID.
Chips are from Mouser, I bought 5, successfully programmed 4 - I can live with that, but it would be lovely if I could resurrect the fifth one somehow.

high voltage parallel programming

Depends what fuse you screwed up. If ytou disabled SPI, then you do need an HV programming method. Not HVPP. HVPP requires at least 16 pins in addition to power and ground, the attiny 85 (and 84, and 841, and - literally - nothing else) doesn't have enough pins! They bodged together this thing they called HVSP. The big nice thing about it is that it requires "only" 6 I/O pins on a tiny85 (ie, every pin, but far better than HVPP, which would need ten pins that don't exist, and those are very hard to connect to.

HVSP also is sort of a symphony of simplified cases:

  1. There are only 6 pins on 85, and I think 8 or 9 (extra pins just being held low to enable it, maybe to make it difficult to do in circuit. I think both of the classic AVR HV modes were intentionally made onerous to use, and impossible to use in circuit on purpose, to throw more obstacles in front of people trying to clone their customers' products, or who want to reprogram hardware which the manufacturer doesn't want reprogrammed.
  2. There are only a grand total of 8 parts in across three part families that use HVSP, and they're pretty popular, and people are more likely to disable reset on a t85 due to pin pressure.
  3. If you consider the unbricking case, you realize that you can guarantee that the fuses aren't blocking ISP programming by using HVSP to write LFUSE to 11100010 (8 MHz internal), HFuse to 1101S111 (S = EESAVE, ) and 0x255 to efuse (ie, the factory standard values except with the clock at 8 meg, to speed up the search.

That is fantastically easier than implementing the general protocol... Look at this madness.... So, you have three lines under your control that are part of the data transmission, One is a clock. The protocol is grouped into units of 11 bits. The first bit and last two bits are always a low on both data lines. the remaining byte is the actual data. And get this, remember how I said there were two data lines controlled by the programmer? Yeah for every clock pulsea bit is clocked into the target from each line, A high fuse write of 11010111 would mean

SDI

0-0100-0000-00 0-1101-0111-00 0_0000_0000_00 0_0000_0000_00

SII:

0-0100-1100-00 0-0010-1100-00 0-0111-0100-00 0_0111_1100_00

As you can imagine, since the three sets of parts can all be restored with the same command, you don't have to implement the full protocol for the general case if all you intend to di is unbrick things. Then it would just need to make it enter programming mode, then send 132 bits on 2 data lines while pulsing the clock. it would be hard to make that not fit in 2048b of flash if you tried, so people would take ATtiny2313's, 12v doorbell battery for the HV, switching the hv with a pair of transistors.

You can find plans for HV debrickers like that online. I don't believe I ever saw an HVPP one though.

But, if all you did was screw up the clock source and set it to a crystal or external clock that isn't present, you don't need to do anything nearly that sophisticated. Take another microcontroller and either set it's clockout fuse (takes manual avrdude invokation) or grab timer1 on something that's not a tiny85, set it to fast PWM mode, the option where it takes ICR1 as TOP. and then set the compare values to either 1 and 3 or 0 and 1, the first one should definitely make PWM a quarter of the system clock. The second one if it works (I forget how low you can crank the period back to on those) gives PWM at half system clock. Or just do a cli; while (1) {PINx |= 1 << (bit position);} which should also be 4 clocks per bit (you do need to cli() to kill interruptsbefore the while loop if bitbanging the clock like that). However you get this MHz speed clock signal from a working AVR, connect it to XTAL1 on the target after disconnecting anything else from that pin, If set to use clock or external crystal, and the "jumpstart" AVR is running at the same voltage and shares a common ground and such, you should now be able to use an ISP programmer on it while it's being clocked from the other signal, and set it to use the internal oscillator, after which the jumpstarter is no longer needed.

1 Like