Loading Profile...
Addresses over 63 freeze the i2c line at random
I have found that addresses become unreliable above 63. You can recreate this bug by loading up BlinkMTester, sending “A64” and then running get address a few times. Usually you only have to request the address about 10 times before it returns “0” once this happens the whole thing locks up.
I am only using the "BlinkM_setRGB" function. Everything works great unless I try to set a color at an address over 63. I'd say each command has a 1 in 20 chance of locking the whole system up. The only solution I have found after this happens is to reset the arduino.
I am only using the "BlinkM_setRGB" function. Everything works great unless I try to set a color at an address over 63. I'd say each command has a 1 in 20 chance of locking the whole system up. The only solution I have found after this happens is to reset the arduino.
I’m frustrated
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Hi,
I'm looking into this now. Do you have another non-Arduino I2C master to try? -
Inappropriate?unfortunately no -
Inappropriate?I can verify that repeatedly calling getAddress occasionally hangs the I2C bus, not just for addresses >64 but for any address. I've also done some stress testing of sending many setRGB commands on a BlinkM at a high address and no hanging occurs.
Here's an addition I made to BlinkMTester in the main command loop:
else if( cmd == 'S' ) {
Serial.print("Stressing BlinkM...");
if( num>0 ) {
for( int i=0; i<(num*10); i++ ) {
BlinkM_setRGB( blinkm_addr, 0,0,0);
delay(10);
BlinkM_setRGB( blinkm_addr, 0xff,0xff,0xff);
delay(10);
}
}
Serial.println("done");
Invoking this clause with "S100" sends 2000 setRGB() commands to the currently selected BlinkM, with ~10 msec delay between commands. The I2C address command I use is often "A79" or "A64". For me this works and does not hang the I2C bus. I am using Arduino-0015 on Mac OS X and an Arduino Diecimila.
I suspect that there is a bug in the I2C response code in either BlinkM or the Arduino Wire library, so that commands that return a value leave the I2C bus in an indeterminate state. I'm still looking into this. -
Inappropriate?Thanks for the help with this! Is there a way to identify and fix a hanging i2c bus in code? That would at least provide me with a hack to get this going in the meantime. I'll try to see what's triggering the hanging i2c bus... Im tesing the LED wall row by row. It usually hangs on the same BlinkM, but it is only happening at addresses higher than 63. I will let you know if I find out any more details.
I’m thankful
-
Inappropriate?I believe I figured out the source of the problem! I put the stress tester function in my code and started stressing different LEDs. The ones on the longest length of bus were the ones hanging. (these coincidentally are all above address 64) I have bus buffers, but apparently they still aren't completely fixing the problem. So I guess the only thing you could help with from your end is a suggestion of how to fix an i2c bus hang. Any ideas?
I’m excited
-
Inappropriate?Hmm... I'll have to do some experiments and get back to you on that. Where I'm going to start is to use the non-Wire-based I2C functions I used in my GPSWiiUI sketch here:
http://todbot.com/arduino/sketches/GP...
and try to create a system with various types of bus hangs and then start instrumenting the functions in "twi_funcs.h" to see where hangs occur and modifying it to develop some non-blocking techniques.
btw, what bus buffers are you using? -
Inappropriate?I'm using the LTC4300A-2 :
http://www.linear.com/pc/productDetai...
My circuit is the same as the application circuit.
I’m excited
-
Inappropriate?OK, well the setRGB calls mostly work but sometimes the BlinkM doesn't change to the color. I would like to use the "getRGBColor()" function to make sure the color changed, but it suffers from the same i2c hanging problem. I'll pay attention to this thread to see if you have figured it out, and I'll try calling Nick tomorrow to see if he has experienced the same problem with his wire library.
Thanks for the help! -
Inappropriate?Something to try: if you can easily swap out the two pull-up resistors on the long-distance SDA & SCL lines, try using 4.7k instead of the 10k in the datasheet. I've found with longer I2C lines, I've needed stronger pull-ups to get around the larger bus capacitance.
-
Inappropriate?Thanks for the help with this. I'm gonna try to optimize the code, and I may divide the bus in two to run it with 2 arduinos as it will probably run faster anyway. Here's a video of the test I got working late last night:
http://www.youtube.com/watch?v=a1ddnk...
I’m thankful
EMPLOYEE
