Get your own customer support community
 

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.
Inappropriate?
7 people have this problem

  • 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.
  • Comment_icon
    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
  • Comment_icon
    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.
  • radiorental
    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.
  • Jim
    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.
  • Jim
    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.
  • Comment_icon
    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).
  • Jim
    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?
  • Comment_icon
    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.
  • Brian Degger
    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
     
    silly I’m learning
    Sprite_screen 1 person says this solves the problem
  • Comment_icon
  • Comment_icon
    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.
  • Babele
    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 :) )
User_default_medium