I bricked an ATtiny trying to get it to sleep

Hi.
I was trying to get sleep mode working on an ATtiny13. I flashed the code in this question, which looks like this:

#include "Arduino.h"
#include <avr/sleep.h>
#include <avr/power.h>

void setup()
{
  cli();  // Disable interrupts

  // Reduce the clock frequency to conserve power
  clock_prescale_set(clock_div_128);

  // Disable all modules
  power_all_disable();
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);

  // Configure all ports as output
  // (does not seem to make any difference)
  DDRB = 0b0011111;
  PORTB = 0;
}    

void loop()
{
  sleep_enable();
  sleep_bod_disable();
  sleep_cpu();
}

Now the Arduino IDE doesn't recognise the ATtiny at all. avrdude returns "error: program enable: target doesn't answer. 1". I added a 1000 millisecond delay to the start of the loop, then stupidly flashed it to another working ATtiny85, assuming the error was in the loop and that the delay would give me a chance to flash something else to it. It did the same thing, so I'm assuming the problem is in the setup function.

It works with a different, working ATtiny85, so I'm guessing it's not my connection. I've tried shorting the reset pin to ground while uploading to no avail. Help would be appreciated.

It shouldn't be possible to brick the chip like this - recheck wiring. ISP uses the reset pin, and hardware reset will reset the chip even when it is sleeping and bring it into programming mode.

Please explain how you attempted to program the ATtiny13, which programming interface was used and how it was wired. Have you ever successfully programmed an ATtiny13?

Housies:
Hi.
I was trying to get sleep mode working on an ATtiny13. I flashed the code in this question, which looks like this:

#include "Arduino.h"

#include <avr/sleep.h>
#include <avr/power.h>

void setup()
{
cli(); // Disable interrupts

// Reduce the clock frequency to conserve power
clock_prescale_set(clock_div_128);

// Disable all modules
power_all_disable();
set_sleep_mode(SLEEP_MODE_PWR_DOWN);

// Configure all ports as output
// (does not seem to make any difference)
DDRB = 0b0011111;
PORTB = 0;
}

void loop()
{
sleep_enable();
sleep_bod_disable();
sleep_cpu();
}



Now the Arduino IDE doesn't recognise the ATtiny at all. avrdude returns "error: program enable: target doesn't answer. 1". I added a 1000 millisecond delay to the start of the loop, then stupidly flashed it to another working ATtiny85, assuming the error was in the loop and that the delay would give me a chance to flash something else to it. It did the same thing, so I'm assuming the problem is in the setup function.

It works with a different, working ATtiny85, so I'm guessing it's not my connection. I've tried shorting the reset pin to ground while uploading to no avail. Help would be appreciated.

That code does not provide any way to wake the CPU up. All you can do is erase it with an ISP to clean out your sleep program. The chip isn't bricked, it's just soundly asleep.

edit to add: The circuit shown at the URL you referenced has the reset button wired wrong... pressing it just shorts out the battery! Helluva power save mode!

I've been using a USBASP programmer. I just tried it using a Pro Mini as an ISP, and it says "Device signature = 0x000000 (retrying)". I've successfully flashed the blink sketch to my good ATtiny85 with it, keeping all the wires in the same place on the breadboard, so I'm confident it's not my wiring. I could program the 13 fine before I uploaded that sleep sketch. I've tried it both with the Arduino IDE and with avrdude in the command line. I've tried force uploading and burning the bootloader without success.

I've successfully flashed the blink sketch to my good ATtiny85 with it, keeping all the wires in the same place on the breadboard, so I'm confident it's not my wiring.

You ARE using bypass caps across the chip power leads, we assume.

If you are, a single success does not exclude intermittent connections. Breadboards are notoriously unreliable.

Take all the wires, chip and bypass capacitor out and move the entire project to a new place on the breadboard, and try again. If it works with the known good chip and fails with another, then you can be confident of a dead chip.

Buy several ATtinys and be prepared to throw one or two out, if you make a mistake. They are very cheap.

I haven't been using a capacitor, and don't have any to hand, so can't try it. The ISP tutorial on the Arduino website says it's only required for some models, and it was working fine without it, so I assumed it wasn't needed. Correct me if I'm wrong.

I've tried a USBASP programmer and using a Pro Mini as an ISP, both on different breadboards, and they both consistently work with my good ATtiny85. I've been programming it and moving it in and out of the breadboard all day, and it works every time. The other two have never worked since I flashed that sketch, so I think it's far more likely that I've done something to them.

You can often, but not always, get the chips to work without a capacitor.

Experienced people always use them. 100 nF across every chip.

Good day,

as a tip for people who end up here by search engines, I can confirm this using an Attiny85. I uploaded a similar code using Arduino and the proper Attinycore without bootloader. This effectively bricks the chip and will not let me upload code or change parameters such as the clock frequency.

The only way to restore the chip was by building a high-voltage-programmer ( ATtiny85 Powered High Voltage AVR Programmer - Hackster.io ), AND clearing the chip using the tips at Removing a Curse from ATtiny85 Fuses

The line that causes the chip to lock up from further programming is:
clock_prescale_set(clock_div_128);

After commenting this out, I can reprogram the chip at will. Leave this command in, and I must use the HVP again.

Looking into this further, it seems it's the same thing that happens when you set the internal oscillator to 128khz by the "Burn bootloader" action. Then your programmer (by default) works too fast to communicate with the attiny, and you have to change the speed of the programmer. Details on that are found on this forum by the name "burnt-wrong-bootloader-oops-attiny84/857875"
( I can only post two links.. )

I just confirmed that this works, and the HVP is not necessary.

1 Like

Confirmed working via salasukka way. Link: Burnt wrong bootloader! Oops! (attiny84) - #5 by DrAzzy

For some reason my arduino would not flash the slow MCU unless GND signal was removed. No idea how that worked...