David Granz's dashboard

Latest update: All 14 Blinkms are continuing to work perfectly. All have retained their programming :)

Btw, http://www.geocities.jp/arduino_dieci...
works great if you don't have a progammer, but do have an Arduino Diecimila

No prob. Hope this is the problem. (fingers crossed)

The BOD set to 0xDD seems to be a good setting. The Blinkm won't work correctly when plugged into an arduino board if the BOD is set to 0xDC (4.5v). It keeps resetting. Perhaps even a 0xDE setting would be safer if you are going to pre-program them.

Well, I'm back from the client with that blinkm string. I've set the BOD on all of them.. Now its just a matter of time to see if the problem goes away.

While had them hooked up to the programmer, I checked the eeprom contents. On the 3 that failed, location 0 of the eeprom (where the unit number is stored), was set to 0, 89, & 0 repectively. Seems consistent with the idea that eeprom corruption is in fact what's happening. The rest of eeprom seemed to be the correct values.

Btw, I found that I needed to set the hfuse value to 0xDD to allow a bit more power leeway. Seems unless I have a really good power supply, there's a bit of droop when several come on at the same time.

Sorry for the very long delay getting back to this problem (was on other projects).

The bug has continued to happen, tho not as frequently. The system is installed at the customer's site. Every once in a while, I have to visit and reprogram a few of the blinkms that have lost their assigned addresses. Note, this system is powered on almost all the time, with very few power on/off cycles. I'm fairly sure the problem is happening when powering off and back on.

Anyway, I noticed an errata on some revs of these chips that says eeprom corruption can occur if the supply voltage drops too low. There are 3 'fuse' bits on the chip that setup minimum operating voltages (Brown-Out Detection). Turns out the blinkms do not have these fuses programmed (BOD disabled). The errata suggests setting a BOD threshold to avoid the eeprom bug.

I've now set all my blinkm's high fuse bits to 0xDC (4.1v - 4.5v Brownout detection). I will now have to wait to see if the problem re-occurs.

Hope this helps
-Dave

Feel free to contact me if you need more info (granz@newl.com)

I'll try to get some code for you when I get back to the office on Tuesday.

Btw, I did check the signals on the data and clock lines with a scope... they are clean with good rising and falling edges.

The bus length is -long-, about 4 feet (they are being used as indicator lamps in a pipe organ console). However I've slowed down the clock/data speed to very slow (sorry I don't have exact timing). There are 4.7k pull-ups at the end of the bus. I had to write standalone bit-banging code to drive the bus as the standard rate on the Arduino board was way too fast. The only command I send to them is the change color command. I do have to update all 14 of them as quickly as possible regularly; I sequentially access each one, setting it's color, every second or so for all of them.

I did numerous tests to determine a max speed for the bit-banging code, and backed off to a safe speed that works reliably. The code uses the Microsecond delay call for timing, about 20us for each bit. I've run the code as slow as 1ms per bit with the same issue of random loosing of the programmed address.
I do get proper 'ack' feed back on each byte transmitted.

A possible scenario is that the glitch occurs when power is lost while sending data. The system may be powered off by the user at anytime, including while I'm sending to the BlinkMs. If I remember correctly, I think the problem happened mostly when I did power on/off tests. Sorry I can't be more specific as each time it happened (at least 5 times yesterday), I had to stop, remove the bad blinkm(s), reprogram the address, and reinstall; making for a rather frustrating day.

Hope that helps.