Bricked Attiny412 after uploading code

Using Arduino LEDs and Multiplexing
1

Hi All!
I have a very strange problem. After uploading the code below, my Attinys ends up bricked and I can't upload anything to them anymore (UPDI initialisation failed).

#include <tinyNeoPixel.h>

#define LED_COUNT 8
#define LED_PIN    PIN_PA1

tinyNeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
  strip.show();
  strip.setBrightness(255);
}


void loop() {
  rainbow(10);
}

void rainbow(int wait) {
  for(long firstPixelHue = 0; firstPixelHue < 5*65536; firstPixelHue += 256) {
    for(int i=0; i<strip.numPixels(); i++) { 
      int pixelHue = firstPixelHue + (i * 65536L / strip.numPixels());
      strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
    }
    strip.show();
    delay(wait);
  }
}

I'm using Arduino IDE 2.2.1 with MegaTinyCore 2.6.8 and FTDI2104 USB-UPDI converter.
Any other program I've tested works fine (including examples from tinyNeoPixel), chips are good as well (tested with Blink example before they stopped responding).

2

That's odd, your code seems fine to me.

So if you upload the code to a T412 even without connecting any neopixels to it the T412 cannot be programmed anymore?

I am curious how you power the setup.

[edit]
While testing your sketch with a T412 and a strip with 60 leds, I noticed that going beyond 24 leds the T412 starts to get memory problems. With your 8 leds it works just fine

Should you want more leds, then the static version of tinyNeoPixel resolves that problem. This sketch works fine with 60 leds from a T412

#include <tinyNeoPixel_Static.h>

#define LED_COUNT 60
#define LED_PIN    PIN_PA1

byte pixels[LED_COUNT * 3];

tinyNeoPixel strip = tinyNeoPixel(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800, pixels);

void setup() {
  pinMode(LED_PIN, OUTPUT); // set pin output - this is not done internally by the library for Static version of library
  strip.begin();
  strip.show();
  strip.setBrightness(255);
}

void loop() {
  rainbow(10);
}

void rainbow(int wait) {
  for(long firstPixelHue = 0; firstPixelHue < 5*65536; firstPixelHue += 256) {
    for(unsigned int i=0; i<strip.numPixels(); i++) { 
      int pixelHue = firstPixelHue + (i * 65536L / strip.numPixels());
      strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
    }
    strip.show();
    delay(wait);
  }
}
3

Yes, the programmer don't see uC anymore, even with all other things disconnected.
The setup is powered from PC's USB port via programmer. LED's work fine with it, the Rainbow example works without problem.

In the meantime I broke another one by just medling with the cables on the breadbord. Maybe they are just that sensitive...
I'm planning to try to program bricked pices with HV programmer in the near future, so I will see if it isn't the problem with the core messing up fuses.

In any case they are so cheap ($0.75) that it isn't much of a loss, but still, I would like to know the source of this unreliability.

4

Extern osc choosen? Try to connect a 1MHz signal to the clock input.

5

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.