BlinkMs blink once with power then die...
We have noticed a problem with a select number of BlinkMs. We received a shipment of 35 of the BlinkM from a distributor, 5 of them were DOA. We are following up for replacements from the distributor, but we were wondering if this was a more frequent problem with users.
This is the symptom:
Power on the BlinkM and the three dies blink once and turn off immediately.
Is this a sign that the ATtiny doesn't contain data or has been flashed?
This is with the BlinkM connected directly to the Arduino or with it stand alone.
This is the symptom:
Power on the BlinkM and the three dies blink once and turn off immediately.
Is this a sign that the ATtiny doesn't contain data or has been flashed?
This is with the BlinkM connected directly to the Arduino or with it stand alone.
7
people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?HI Rob,
An unprogrammed BlinkM will do nothing when connected to power. Generally, if a BlinkM starts to power up then stops, it's an indication the power supply going to the BlinkM is noisy or can't supply enough to power a BlinkM.
If your power is good, then it sounds like the BlinkMs got fried somehow, either permanently or the flash got corrupted.
If you have an AVRISP programmer and a breadboard, you can try reflashing the BlinkMs using the wiring diagram described in the datasheet and using the standard BlinkM firmware.
If you'd like to exchange the bad BlinkMs, feel free to contact us directly at blinkm @ thingm.com and we can arrange for replacements. This will let us do forensics on the BlinkMs to see how they died. -
I have this same problem. I was playing around with the code examples. I guess I may have inadvertently plugged my blinkMs in to the arduino while it was powered up... (yes I realise its in big bad red letters not to do so (o;)
So, now both my blinkMs are blipping all 3 dies on and then nothing.
Can I recover them? thanks /pauric -
radiorental, if you have access to an AVRISP programmer, you can try reflashing the BlinkM firmware. The datasheet has a description of how to wire up a BlinkM for that. -
Inappropriate?I do not, just an arduino. Unless thats a AVRISP programmer and I can add one more thing to the world of stuff I dont know.
-
Inappropriate?After flashing the firmware, adding the .eep gives me this error:
C:\BlinkM>avrdude -c stk500v1 -p ATtiny45 -P com3 -U eeprom:w:blinkmv1.eep
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny45
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9206
avrdude: reading input file "blinkmv1.eep"
avrdude: input file blinkmv1.eep auto detected as Intel Hex
avrdude: writing eeprom (39 bytes):
Writing | ################################################## | 100% 0.30s
avrdude: 39 bytes of eeprom written
avrdude: verifying eeprom memory against blinkmv1.eep:
avrdude: load data eeprom data from input file blinkmv1.eep:
avrdude: input file blinkmv1.eep auto detected as Intel Hex
avrdude: input file blinkmv1.eep contains 39 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 0.05s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0002
0x00 != 0x08
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK
avrdude done. Thank you. -
Inappropriate?ack... looks like my first post got wacked - the one above shows an .eep upload error.... not sure what is going on there.
History - same problem as the parent post - blinkm worked fine on Arduino, then didn't... would blink once, then go out...not sure if I zapped something or what. Flashed the firmware with ISP - LED blinks like crazy during upload. Put back on arduino... now nothing. Any ideas?
Firmware output:
C:\BlinkM>avrdude -c stk500v1 -p ATtiny45 -P com3 -U flash:w:blinkmv1.hex
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny45
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9206
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny45
avrdude: reading input file "blinkmv1.hex"
avrdude: input file blinkmv1.hex auto detected as Intel Hex
avrdude: writing flash (3882 bytes):
Writing | ################################################## | 100% 2.61s
avrdude: 3882 bytes of flash written
avrdude: verifying flash memory against blinkmv1.hex:
avrdude: load data flash data from input file blinkmv1.hex:
avrdude: input file blinkmv1.hex auto detected as Intel Hex
avrdude: input file blinkmv1.hex contains 3882 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.19s
avrdude: verifying ...
avrdude: 3882 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you. -
Hi Jim,
If you were able to flash it successfully, chances are the BlinkM works, but it's either not playing its startup script (or it's playing a blank script). Try talking to it with an Arduino and the BlinkMTester sketch and see what happens.
In general, we recommend using the Makefile that comes in the firmware zip, modifying it where appropriate for your programmer. Then, doing a "make erase" and "make program" to fully reset a BlinkM to its factory condition.
And yes, because of how the BlinkM is wired up, you should see the blue LED flash during programming (and only the blue). -
Inappropriate?I'm new to AVR and ISP so I might be screwing something up... I edited the makefile to my specifics than ran it... still get a verify error.
C:\BlinkM>make -f Makefile-dist
avrdude -p attiny45 -P com3 -c stk500v1 -v -v -y -e -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m -U efuse:w:0xFE:m -e -U fla
sh:w:blinkmv1.hex -U eeprom:w:blinkmv1.eep
avrdude: Version 5.5, compiled on Jun 9 2008 at 14:32:04
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
System wide configuration file is "C:\WinAVR-20080610\bin\avrdude.conf"
Using Port : com3
Using Programmer : stk500v1
AVR Part : ATtiny45
Chip Erase delay : 4500 us
PAGEL : P00
BS2 : P00
RESET disposition : possible i/o
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 6 4 0 no 256 4 0 4000 4500 0xff 0xff
flash 65 6 32 0 yes 4096 64 64 4500 4500 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 1
Firmware Version: 1.15
Vtarget : 5.0 V
Varef : 5.0 V
Oscillator : 3.686 MHz
SCK period : 1.1 us
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny45
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9206
avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FE
avrdude: erasing chip
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny45
avrdude: erase-rewrite cycle count is now 3
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:
avrdude: load data hfuse data from input file 0xDF:
avrdude: input file 0xDF contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFE"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFE:
avrdude: load data efuse data from input file 0xFE:
avrdude: input file 0xFE contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "blinkmv1.hex"
avrdude: input file blinkmv1.hex auto detected as Intel Hex
avrdude: writing flash (3882 bytes):
Writing | ################################################## | 100% 2.61s
avrdude: 3882 bytes of flash written
avrdude: verifying flash memory against blinkmv1.hex:
avrdude: load data flash data from input file blinkmv1.hex:
avrdude: input file blinkmv1.hex auto detected as Intel Hex
avrdude: input file blinkmv1.hex contains 3882 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.19s
avrdude: verifying ...
avrdude: 3882 bytes of flash verified
avrdude: reading input file "blinkmv1.eep"
avrdude: input file blinkmv1.eep auto detected as Intel Hex
avrdude: writing eeprom (39 bytes):
Writing | ################################################## | 100% 0.28s
avrdude: 39 bytes of eeprom written
avrdude: verifying eeprom memory against blinkmv1.eep:
avrdude: load data eeprom data from input file blinkmv1.eep:
avrdude: input file blinkmv1.eep auto detected as Intel Hex
avrdude: input file blinkmv1.eep contains 39 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 0.06s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0002
0x00 != 0x08
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FE
avrdude: safemode: Fuses OK
avrdude done. Thank you.
make: *** [eraseprogram] Error 1
-----
Did I do anything wrong here? -
Hi Jim, It doesn't look like you've done anything wrong. It looks like the EEPROM won't verify, a condition I've only seen when I've unplugged a BlinkM in the middle of programming. I'd like to look at it now and see what's wrong.
Email us at blinkm [at] thingm.com we can arrange a replacement. Apologies you had some bad luck with it. -
Inappropriate?I had this problem with one of my BlinkMs, out of four, related to plugging in a power source (4.5v 3xaa)
wrong.
Do as todbot suggested, the blinkMTester should still work, even if they blink, then 'die'.
Somehow the startup sequence has been corrupted with the fade speed turned down in the startup parameters, and/or the startup script is blank (script 0).
There should be no need to reflash the chip.
In blinkMTester, first type a, to get the address
it should register as 9, if it says 97, D and C lines on the blinkM aren't hooked up correctly
then type cFFFFF this will make the led full white
then type f100, this will make sure that the fade speed is ok/not zero
then type p16 this will play the lightning script which has occasional flashes of white..
using the tester you can also reset the startup parameters
from the BlinkM tester issue the command
B 1 12 30 20 -5 (see pg 16 of the blinkM v1 datasheet for description of paprameters)
hope this helps,
Brian
I’m learning
1 person says
this solves the problem
-
that worked a treat - thanks Brian! -
Hi, I have 4 blinkms, I uset them with some solar-powered rechargeable power source, so it is easy they have been under-powered, and I experimented the same problem many times on more of them. Being sure they could have not died, I just tried the same thing - attaching them to Arduino and resetting the default startup sequence. It works, even this is an annoying behaviour. It seems to be related to low-power setup, nearly died batteries, Joule Thiefs and the similar... -
Inappropriate?Hi Babele,
When you say "resetting the default startup sequence", exactly how are you doing this? I'm just curious.
BlinkM is designed for operating at a constant voltage between 3.6V - 5.0V, but it should work (within reason) with a low or changing voltage source. (Note that by their very nature, the blue LEDs in BlinkM need about 3.6V to turn on, and the green ones need about 3.2V)
Solar-powered circuits driving microprocessor systems typically have voltage regulators and large-ish capacitors to make the power as stable as possible.
The low and varying voltage it sounds like you have could be causing causing brownouts in the chip and triggering EEPROM corruption. This is what the brownout detector and fuse settings for it mentioned above are meant to prevent. You may have the older fuse settings from an earlier BlinkM batch. If you have access to an AVR programmer dongle, I can walk you through the steps to change the fuses on your BlinkMs. Alternately, you can email us at blinkm at thingm.com and we'll arrange an exchange. -
Inappropriate?Hi Tod,
I realized I was a bit criptic. Excuse me. What I mean is, I just rewrote the params for the startup script. In fact I did this a lot of time ago, so I just do it again now: I have 4 BlinkM, all connected in parallel (both power and I2C). Two of them exibit the "just flash on power up and nothing more" behaviour.
So I get my Arduino, connect everything, and load this:
#include "Wire.h"
void setup()
{
Wire.begin(); // set up I2C
Wire.beginTransmission(0x00); // join I2C, talk to everybody
Wire.send('B'); // set startup parameters
Wire.send(0x01); // play a script
Wire.send(11); // play script 11
Wire.send(0x00); // repeat forever
Wire.send(0x5); // fade level
Wire.send(50); // time adjust
Wire.endTransmission(); // leave I2C bus
}
void loop()
{
}
I compile and upload and reset the Arduino. Nothing. I disconnect the arduino from USB and reconnect it, and voila! All my 4 BlinkM are now shining in full glory (and sync, at least for a minute or so...) ...(why wasn't the soft reset enough? I am a SW developer. I learned not to ask when something works.)
So, it seems definitely related to fade speed, or time, I don't know. When it first happened, I thought I had burnt my blinkm, then I thought it was impossible, and I noticed the fast "flash". Then I just thought to my old Moog and when it was not doing any sound, and I thought it was broken and instead it was just the sound envelope too fast to be heard... I experimented with some values for fade and time, and I got this sketch hereabove.
solar power: yup.. I am using this board:
http://www.sparkfun.com/commerce/prod...
it has also a voltage multiplier, as you can see. No big capacitors, though... I should have thought it by myself. thx!
More than once, I left the blinkms attached until the rechargeable battery completely discharged (or, at least, there was no power enough to lit the BlinkMs. In fact I noticed the three RGB colors have different minimum voltage levels..). Maybe THAT is a possible reason for the problem?
EEPROM corruption: I have read all the thread. No, I have no way to reprogram it, and I am in Italy and sending you back the BlinkMs would cost a lot of money. In any case, it seems to me that there was NO corruption.. my BlinkMs works perfectly now... That fix should be done to AVOID such "forgetting something" behaviours, right?
Or you mean that the BlinkMs could really "break" - I mean, some meaningful firmware bit could die because of that fuses and brownouts and it could become impossible to "reset" them the way I did just hereabove?
Nonetheless, it IS annoying.. also because I plan to do some sequencing, so I will probably hit the I2C forgetting-address bug myself. I'll keep you informed.
Thank you very much for your interest and message. I was a youngster intrigued with electronics, some 30 years ago.. Now I am trying to understand what happened in the meanwhile (once you used a 555 to get a blinking LED.... now you use a microprocessor and write some code :) )
Loading Profile...



EMPLOYEE
