todbot's dashboard

Hi,
That's a really beautiful lamp.
GetSatisfaction currently screws up code formatting, so it's hard to see if the oddities in your sketch are from you or being mistranslated. Please email me your sketch at blinkm at thingm.com.
When you say "add more steps", I assume you mean adding more if-statements?

Okay, thanks for the help ;)
Keep up the good work !

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?

You can set whether or not a startup script should play, which script to play, and how many times to play it with the 'B' (Set Startup Parameters) command.

The 'o' (Stop Script) command and the 'p' (Play Script) command let's you stop and start a light script arbitrarily, like a play/stop button. They're not meant to change the startup behavior.

Thanks for the answer, it works fine if I send "o" before any other command. But why do the default power-on light script continuie to play? Is it a bug ? Can I fix it ?

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.

Hi Julien,
It sounds like something is sending another color command to your BlinkM. This is usually due to the default power-on light script continuing to play. To stop it playing, send the "stop script" command ('o') to it. If you're already doing that, check your code to make sure you're not sending other commands to the BlinkM. Can you post the code that's controlling the BlinkM here?

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

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, on August 22, 2008 19:12

Hi Matteo,

I2C is an asymmetric protocol: a typical bus has one I2C master and one or more I2C slave. The Arduino Wire library is how to do an I2C master. You need code on how to make an I2C slave.

Atmel provides a pretty good application note in "AVR312: Using the USI module as a I2C slave". Scroll down to download it here: http://atmel.com/dyn/products/app_not...
It's interesting if you want to know some of the theory behind how it works.

For more immediate results, you can find examples of people using this application note on the net. One of the best examples is d.tools, http://hci.stanford.edu/research/dtools/ and you can look at the source code to many different kinds of I2C slaves they've implemented here: http://d-tools.cvs.sourceforge.net/d-....

I think the d.tools examples are using the IAR compiler instead of the AVR-GCC compiler. There's no real difference, just slight syntax changes for a few things. To see an avr-gcc examples, poke around on avrfreaks.net. There's a few projects and forum posts that port AVR312 appnote. For example, here's one: http://www.avrfreaks.net/index.php?mo...

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.

Excellent, I will try the power supply issue first. I'll be documenting my work for all to see when this network is up and running. We have some sensors running as well so power will be an issue for sure.
Thanks for all your help.

-Rob