Arduino blocks i2c bus

Hi everyone, I have some Unos (2 right now) hooked up to a Raspberry Pi's i2c bus, with the Pi as the master. When Pi writes to one Arduino (device 0x05 from henceforth) for the 261st time, it's not there. Actually, the Pi cannot find either Arduino on the bus, and both of them were there before. If I reset 0x05, both 0x05 and 0x04 (the other Arduino, which has not been reset or written to) come back on the bus. They don't reappear if I reset 0x04. If I tell the Pi to write to 0x04, nothing disappears.Their software is identical except for their i2c address. The question for you all is, is there a reason this Arduino appears to be jamming up the bus on 260th read?

You could really help us to help you by providing schematic(s) and code. See "Read this before posting a programming question ..." http://forum.arduino.cc/index.php?topic=97455.0.

Because both are coded using the same sketch I would be inclined to take a look at the hardware.

Make sure all your I2C lines are the same length. Don't run Arduino(1)'s I2C lines parallel to Arduino(2)'s . Make sure you have good tight connections at the circuit (or proto) board. Even a single slightly loose or corroded wire could cause enough problems with line signals to lock up one or both of the microcontrollers (Arduinos.)

Anything else will have to wait for schematics and code. Pictures would be nice, too. ;)

By parallel do you mean physically or electrically?

Here’s the code I’m running:

#include "Tlc5940.h"
#include <Wire.h>

boolean led_no = true; //check if i2c comm is the led addr byte or addr byte
int intensity; // how bright is the led
byte led_address; // led's pos in str on this arduino, no actual bearing on location
int blank_pin = 4;
boolean recd = false;

void setup(){
  int i2c_address = 6; //which arduino is this
  Wire.begin(i2c_address); //start i2c
  Wire.onReceive(rec_event); //register function to rec data
  Tlc.init(); //begin the TLC 5940 library
  //pinMode(blank_pin, INPUT);
  //Serial.begin(9600);
}

void loop(){
//  if(digitalRead(blank_pin) == 1){
//    Tlc.clear();
//    Tlc.update();
//  }
  if(recd){
    Tlc.update();
    recd = false;
  }
}
void rec_event(int bytes_recd){
  if(Wire.available() > 1){
    led_address = Wire.read();
    intensity = map(Wire.read(), 0, 255, 0, 4095);
    Tlc.set(led_address, intensity);
    recd = true;
  }
}

And an image (link, not sure how to embbed): arduino iic setup.jpg - Google Drive

Actually, I should mention that it doesn't make a difference whether or not the working Arduino is there or not. I also noticed that the working Arduino is an original Uno, while the failing one is an Uno r3. My Pi's PSU seems to failed suddenly, so I can't test whether the other original one I have is doing this.

What we mean is draw a schematic with pen and paper , photograph it with your cell phone and post it.

Duh. Here: https://drive.google.com/file/d/0BwtZtfwjz_Mwc01QbXhRak1ab28/edit?usp=sharing

Duh, That's link . browsers don't have rotate function. That's not going to work . I meant upload the jpeg file , not a link. If you don't know how to upload a file just ask. (Additional Options) below, lower left corner, (duh)

By parallel do you mean physically or electrically?

It's the same thing. It's called Mutual Coupling. It is the reason signal wires are typically twisted pairs .(duh)

Duh. Here: https://drive.google.com/file/d/0BwtZtfwjz_Mwc01QbXhRak1ab28/edit?usp=sharing

What's wrong (missing) with this picture ?

I have some Unos (2 right now) hooked up to a Raspberry Pi's i2c bus, with the Pi as the master. When Pi writes to one Arduino (device 0x05 from henceforth) for the 261st time, it's not there. Actually, the Pi cannot find either Arduino on the bus, and both of them were there before. If I reset 0x05, both 0x05 and 0x04 (the other Arduino, which has not been reset or written to) come back on the bus. They don't reappear if I reset 0x04. If I tell the Pi to write to 0x04, nothing disappears.Their software is identical except for their i2c address. The question for you all is, is there a reason this Arduino appears to be jamming up the bus on 260th read?

What are the above conclusions based on ? (do you have a I2C Sniffer ?) How do you know what is on the bus or off the bus ? How about explaining how what your conclusions are based on.

raschemmel: What's wrong (missing) with this picture ?

No pullup resistors. I'm not sure whether the Pi has any. I'd be using 2.2K pullups for sure.

But I doubt that lack of pullups, or wiring or connection issues are causing the problem, if it occurs consistently after 260 I/Os. Funny number, 260. Is it always exactly the same?

Is there a buffer used for I2C like a serial receive buffer ? Maybe the memory is filling up. Maybe there is a FLUSH command to empty the buffer (if there is one). Interesting . If you devide 260/8 =8.125 , but 8*32=256. http://forum.arduino.cc/index.php?topic=54439.0

raschemmel: Is there a buffer used for I2C like a serial receive buffer ?

Yes, 32 bytes. I also note that the code below assumes that there are two bytes to read. Can't say for sure that it's causing a problem, but I'd at least test the value of bytes_read to ensure I'm getting what's expected. Overrun them buffers, next thing you know, someone will steal all your customers' credit card numbers ;)

void rec_event(int bytes_recd){
  if(Wire.available() > 1){
    led_address = Wire.read();
    intensity = map(Wire.read(), 0, 255, 0, 4095);
    Tlc.set(led_address, intensity);
    recd = true;
  }
}

Have a look at this post (sound familiar ;)) http://forum.arduino.cc/index.php/topic,38118.0.html

farTooManyWires:
By parallel do you mean physically or electrically?

<code snipped, I’m not replying regarding code…>

And an image (link, not sure how to embbed): arduino iic setup.jpg - Google Drive

I keep looking at where the power wires are going. I see on the r3 you have it connected via USB and the red jumper is connected to 5V. This seems to indicate to me that you are sourcing power from the r3. Is this correct? If so, then powering 2 Arduinos only leaves about 100mA to 260mA left to power what ever is on the other end of the alligator clips. You may be experiencing brown outs if you are trying to pull more than 500mA from the USB port.

I see on the older UNO that you have the red jumper to Vin. This pin has the same restrictions as the barrel jack, in that it should be at least 2V higher than 5V, not the 5V your are feeding it from the r3 (if that is indeed the source).

Where are the alligator clipped power jumper wires going at the top of the picture? If that is the voltage source, what is that voltage source set at? If greater than 5V you may be on the way (or already have) fried your r3. If it is set at 5V (and is well regulated) you should also have the older UNO connected to it via the 5V pin for the same reason as the previous paragraph.

One further comment about your wiring… avoiding wiring mistakes (and asking us to help) would be greatly assisted if you didn’t use yellow for both SDA and SCK…

(One nice thing about pictures of rats nest of wires, it is at least how things actually are wired, instead of how things are intended to be wired from a schematic or sketch. But they can sometimes be a bear to figure out, even with multiple angles…)

Thanks for all the replies everyone!

Power: The USB cable was not the power source, it was there for downloading code. The actual source was a 10v regulated bench supply to the Vin pins.

Buffer: I don't see a flush command in the wire library, and the stream library's flush command seems to be for the outgoing buffer, which makes me assume that it flushes the incoming buffer on its own.

I2C packet: The reason it reads in two i2c packets is that the master (the Pi) sends two packets every time. It's running a python script that writes a command byte and data byte, which is the same as writing two bytes, according to my testing.

The 260 number is (actually double that, 520, looking back at the code) from a test script that I wrote. The arduinos are hooked up to a bunch of TLC5940 chips, which are led controllers. The script was designed to flash every LED on the off in series. This means that with every cycle, the python program 1) prints the number of the LED it's going to turn on 2) writes a command byte with that number 3) writes a data byte with the intensity (55) 4) waits 0.1 seconds 5) turns off that led by writing a command byte with the address and a data byte with intensity 0 6) waits 0.1 seconds 7) repeats with the next LED. This loop goes from led 0-240. When the script prints 130, the first write to the Arudino fails, saying it's disconnected. This is the 261st command issued from the Pi, but would have been the 521st packet received on the Arduino. I therefore assumed (dangerous, I know) that the 520th packet received in the arduino that caused the problem. I don't think it's that, because the other arduino does not have the same problem

i2c bus: my conclusions about what is on the bus are based on a) the fact that writes from the pi fail, and b) the i2cdetect command on the pi shows nothing. As far as I know, the i2c detect program sends some data to all addresses and tells who replies.

farTooManyWires: Thanks for all the replies everyone!

Power: The USB cable was not the power source, it was there for downloading code. The actual source was a 10v regulated bench supply to the Vin pins.

Yet if you look carefully at your dropbox picture of how things were actually wired, you have a red power wire going from the breadboard to the 5V pin of your UNOr3 (the one in the upper right of the picture). I'm not sure how you didn't release the magic smoke with twice the voltage...

You are very right, sir. I thought I checked those. Maybe I need more or less coffee. I'm not sure what affect that might have on the I2C problem, but all the Arduinos still seem to work fine.

The two Arduinos run identical code, except for their I2C address? Have you tried changing the addresses? Does the problem move with the address or stay with the board?

The problem stays with the board, no matter the address, or whether it is higher or lower than the address of the other device on the bus, or whether it is the only device on the bus.