Rob Edwards's dashboard

I can't quite parse what you said in your last comment. Could you rephrase it? – todbot, on October 02, 2008 05:09

-> i am trying to identify if the problem had a link with the i2c bus by programming a starting sequence with sequencer and defining an address to concerned led and just putting 5v without connecting them to an i2C bus

Arnaud – Arnaud, on October 01, 2008 22:59

I have reprogrammed the default sequence with communiator and sequencer.
But the concerned led with the problem lost these sequences too. As far as i remember, concerned leds maintained the programmed sequence and the channel number when it stays plugged on 5v. When I unplug and replug power, let say 5 times, almost every concerned led lost their information.

My pull up resistors are on a shield up to the arduino board between 5v of arduino and respectively SDA and SCL. grounds are common between arduino voltage regulator and the dedicated one for leds (78T05N -> 5V 3A for 10 leds and 20 in the futur, with all the capacitors to maintain a perfect 5V even when the leds are blinking -> verified with oscilo).

Best thing i can do is send you the leds concerned asap to let you have a hand on it.
For information, I bought the leds at lextronic (France) 10 days ago.

Hi Arnaud,
Thank you, this is helpful. I've tried similar arrangements of BlinkMs but haven't seen problems yet. I'll try again, replicating your exact setup.

You say you have pull-up resistors, could you describe exactly how you have them wired up? Or attached a schematic or diagram image showing the connections?

Address 0 is the "broadcast" address in I2C, so every BlinkM should respond to commands sent to it.

Do the BlinkMs that have lost their address still play the default startup light script (white->red->green->blue->off->repeat)?

I have the same problem : I use an arduino board, and a strip of ten blinkm. pull up resistor are on the 5v of the arduino and the blinkm are powered with a separated regulator (common GND).
the 4 same blinkm lost their adress when i repower few time everything.

So to detect what is going wrong i wrote a setup wich makes blink each blinkm on each canal of the i2c bus :
////
int i ;
for(int i = 1 ; i <= num_led;i++)
{
BlinkM_setRGB(0x00,0x0,0x0,0x0);
delay(5);
BlinkM_setRGB(i,0xFF,0xFF,0xFF);

delay(300);
Serial.print("canal : "); Serial.println(i);
}
////

After a reprogrammation and some reboots + sequence, i found that it is the same leds wich lost their adress and have most of the time taken an adresse of an other led between the losts leds . Whatever, they respond to canal 0

Maybe it is the corruption of a bit in the address. Is there some CRC made on the adresse in the attiny45 of the blinkm ?

Arnaud

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

When reporting to Todd It will be helpful to list the number of BlinkM's online and the type and size of the power supply used as well to help eliminate issues that might be related to power fluctuations or surges during use..

Will

zschallz (and anyone), if you have a failed BlinkM, contact us at blinkm at thingm.com and we'll arrange replacements for you.

As for the I2C address problem, I'd really like to find a way to reproduce this bug and squash it. If anyone has a setup that pretty reliably does it, I'd definitely like to see some pictures, diagrams, code, etc. of it. Or if you'd like to share the process you go through where this has happened before. For code snippets, email us at blinkm at thingm.com (since GetSatisfaction doesnt do code snippets very well)

Any Ideas? My research group is sending this project out to present it a few states away and in the UK. If possible, I'd rather not have spent $400 dollars on LEDs and have them botch up 6000 miles away. :(

As an update, one of the BlinkMs that lost its address seems to have died. It now blinks once when powered, and accepts no commands and plays no scripts afterwards. Many others BlinkMs in my shipment arrived like this as well, but I have not had the chance to test all of them.

Thank you.

I have experienced this problem too-- it is very annoying. I purchased a very large amount of BlinkMs because I thought they would be more reliable as a networked array of leds opposed to a wire to teach LED, but this makes it probably less reliable. I am using 14 BlinkMs on an ribbon cable similar to the Cylon project; one time while filming the project I tried updating an led to a different color and bam, it and the one next to it lost its address. :( The operating system also said that USB had been unplugged (it had not been) probably meaning the Arduino reset. If you'd like to see code, please let me know. (though it is very similar to the cylon project)

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. – todbot, on August 29, 2008 23:29

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,
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). – todbot, on August 28, 2008 04:07

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.

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.

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.

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. – todbot, on August 22, 2008 19:14