ATtiny85 bricks after repeated power-ups

[46lukasz]

Hello,

I recently started playing with the ATtiny85 for a project involving an LED strip with individually addressable LEDs.

My code works fine but i have bricked 3 Digi spark style boards so far.

First one got bricked when I was powering it on and off repeatedly to test for robustness.
The second one got bricked when i powered it up one time, totally random event.
The third one got bricked as a result of me trying to find the cause of this happening. I was toggling the power on and off really quickly and after a few seconds of it, it got bricked like the previous two.

I am using an external 12v supply, but these boards have an on-board V-regulator.

By bricked I mean there is nothing happening when power is connected, the power LED on the board lights up but the LED strip doesn't light up like its programmed to do.

Little bit about my configuration:
Before any of this happened, i uploaded a different bootloader to remove the startup delay, which gives you a time window to plug in the board and upload code (after this change, it is needed to short P0 and GND to upload code).
The next thing i did was disable the reset function of P5, to turn it into a GPIO pin. This was done by setting the fuses through an Arduino as an ISP and an avrdude command.

After my problem happens and i try to fix it by reuploading the bootloader, i get the error Device Signature is Invalid. I assume that it is because the reset pin is disabled, hence i can't reupload the bootloader, I realise that this could possibly be fixed with a high voltage programmer.

So, i am wondering why this is happening and how i could protect my project from it?
Has anyone seen something like this happen to them?

My project would be finished and working by now, but because there is a random chance of this happening on power-up, i see it as unstable and don't want to use it. I am thinking about going with a different MCU instead.

Any help would be appreciated!

[gilshultz]

I have seen this on other systems and it almost always if the reset parameters are not followed properly. A LVD (low-voltage detect) is needed. This is an external part that generates a reset signal when the Vcc supply voltage falls below Vref. It will not come out of reset until the power has stabilized. This can be combined with power-on reset it is called POR-LVD.

Microprocessors will run executing instructions even when the voltage is low or the memory does not respond correctly. The code they run is random and can access and change anything on the processor.

On my systems if I detect a fault I power down the processor and perherpials waite a while then restart by powering back up. I do it with a MOSFET so I get a solid turn on, not a sloppy that will causes problems.

There are thousands of pages written on reset problems. This is my opinion not shared by all but definitely by many.

They sell regulators etc that have an extra pin to do this function.

[46lukasz]

Thanks for your input. Perhaps there was some ripple or bounce when connecting to my 12v source supply by hand, which caused the problems you talked about.

In my project the final power source will be wired permanently and turned on by a solid state relay, hopefully this will reduce bounce.

In the meantime I built a high voltage programmer according to this webside, however it created more questions than answers.

When attempting to reset the fuses to default, i get the following failure as the device is not recognised as ATtiny85, and the script doesn't even attempt to write the fuses:

Reading signature from connected ATtiny......
Reading complete..
Signature is: FFFF
Reading fuse settings from connected ATtiny.......
LFuse: FF, HFuse: FF, EFuse: FF
Reading complete..
Fuses will be read again to check if it's changed successfully..
Reading fuse settings from connected ATtiny.......
LFuse: FF, HFuse: FF, EFuse: FF
Reading complete..

But when I disconnect the transistor that controls the high voltage to the reset pin, I get the following output, which indicates the device is recognised but the fuses remain untouched.

Reading signature from connected ATtiny......
Reading complete..
Signature is: 930B
Reading fuse settings from connected ATtiny.......
LFuse: E1, HFuse: 5F, 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: E1, HFuse: 5F, EFuse: FE
Reading complete..

any ideas?

[46lukasz]

ok so it turned out the transistor to control the high voltage to the reset pit was the wrong way around and it gave the signature as FFFF,

When turned it around i the signature was 930B so it was OK. I managed to fix 1 board but the rest still give incorrect signatures so i guess they are dead for good.

Like gilshultz said above, most likely the error was caused by too low voltage at which the board tried to operate when i was toggling power on and off very quickly and it got corrupted. Here is another good explanation i found:

When the supply voltage to an ATTINY gets too low, all bets are off and things can get f*'ed up. The minimum safe voltage is dependent on clock speed, but always greater than 1.8V for ATTINYs (except for this very special one)...
at lower voltage the chip may power up and run random code – flash or EEPROM corruptions are also apparently possible.

I also found a solution to this which corresponds to a low-voltage detect again mentioned by gilshultz. on the ATtiny85 it is a brown-out detect protection system which puts the chip into reset once supply drops below a preset voltage. This is done by configuring the fuses on the chip. More about this on this fuse calculator website: AVR® Fuse Calculator – The Engbedded Blog

I set mine to 2.7v which is above the minimum recommended 1.8v. I then spammed the power switch quickly but the problem didn't occur. I can now say my project is going to be stable.

more about brown-out on the tiny85 here here, and here

How to unbrick the board is here, although the schematic connections and the pins in the code are not the same and need to be changed.

[gilshultz]

I did not use the brownout detect because it only reset the microprocessor and not the external hardware. I have a hardware one that shuts the power down to the processor and peripherals, pauses a few seconds and starts it back up. This keep doing this until it gets a diet of positive going pulses. My projects have no requirement to get out of reset quickly so no problems. I love long resets.