Author Topic: Bricked with common-anode RGB LED?  (Read 2370 times)

ax0n

  • Newbie
  • *
  • Posts: 2
Bricked with common-anode RGB LED?
« on: August 29, 2014, 08:01:01 am »
I seem to have bricked one of my kickstarter-editions.

I had been playing with PWM and I2C on it. Then I found an RGB LED in my pile of stuff. It was a radio-shack "full color common anode" LED connected as shown in the attached image. This LED differs in that you supply voltage to pin two, then pull the other legs to ground to get red, green and blue.

Testing, I found that the PWM pins pull the pin to ground when not pushing voltage, so I connected the LED as-is for the DigiSparkRGB example, except ran the common pin to +v5 through a 2.2kΩ resistor. I initially started with a 330Ω, but it was too bright to look at.

It ran in this configuration for quite some time, probably an hour or so. I didn't see it lock up, but it eventually did, while I was getting i2c stuff programmed into my raspberry pi. I glanced at it, and the RGB LED was glowing a faint blue, with the PWM LED also glowing faintly (the same pin controlling the blue element). Unplugging the RGB LED, the PWM LED on-board goes out, telling me that the digispark isn't really in control of that pin anymore.

Digispark will not program. Micronucleus cannot see it. Resetting it, it no longer attempts to run the DigisparkRGB code I had last loaded onto it.

These are so inexpensive that it's not worth my time trying to fix the digispark itself. I WOULD, however, like to not brick a microcontroller in this way in the future. Can anyone tell me what might have gone wrong here, and if I should have set up the LED differently?


ax0n

  • Newbie
  • *
  • Posts: 2
Re: Bricked with common-anode RGB LED?
« Reply #1 on: August 30, 2014, 07:52:52 am »
I used 3 2.2k resistors (one for each cathode) and ran the anode straight to the 5v rail, and left similar code running on a different digispark all night (about 12 hours) and it's still running fine. I don't know if the slightly modified setup is actually safer or better in any way, but it seems like this issue is resolved for me.