I2C read problem

Firmware
1

I am porting some Arduino code that looks like this:

Wire.beginTransmission(addr);
Wire.write(byte);
Wire.endTransmission();
Wire.beginTransmission(addr);
Wire.requestFrom(addr, 1);
b = Wire.read();
Wire.endTransmission();

Right now, my loop just calls this over and over again (for testing purposes) and toggles the onboard LED. What I am seeing is that after a variable amount of time after starting up, the wall clock time consumed by this code suddenly changes from too-short-to-detect-by-eye per loop iteration to ~500ms per loop iteration.

The change that I made to seemingly fix the problem is to add

while(!Wire.available()) {
    delay(1);
}

before the call to Wire.read.

Now, this is weird, because my understanding (from reading the firmware code) is that requestFrom is supposed to include a blocking read, so the internal I2C buffer should contain at least one byte before read is called. I am open to suggestions as to what is going on here.

(I do have 3 kΩ pull-ups on SCA and SCL, which meet the algorithm given in http://www.ti.com/lit/an/slva689/slva689.pdf.)

2

Hmm, im experiencing something similar, im not sure if its the same.

Ill try your fix in the next couple of days and see if it helps my code too.

would you not be better with something like this? maybe you could also add a timeout in case nothing is received? and maybe count the number of bytes received to make sure you read the right amount back

while(!Wire.available());
while(Wire.available()){
    b=Wire.read();
}
3

I had some issues with i2c, I’d suggest that you update the photon firmware to 0.4.3 if you’ve not already done so. HTH

Robin

4

I’ve found it… challenging… to figure out exactly what version of firmware I am running (due to cryptic MCU output in DFU mode), and to figure out whether my attempt at flashing 4.3 firmware has been successful (due to dfu-util saying “dfu-util: Invalid DFU suffix signature”). So I am kind of hoping to dodge having to figure all that out by sitting on my hands long enough for 4.3 firmware to be pushed out to Web IDE :smile:

But yeah, I noticed that pre-4.3 people were having lots of issues with I2C and perhaps I should just sit one patch out and see if the problem goes away. Because, really, at this point it’s either that or I have to wrestle with a protocol analyzer…

@Hootie81: The code you wrote is basically the same as mine for my situation, because I am only reading one byte. And yeah, there is all sorts of defensive programming I can slap onto this — checking the amount of data received, handling timeouts, etc, but I am trying to make sure that I am not just papering over firmware bugs.

5

There is a thread on how to check the firmware version and how to decipher the cryptic response.

Dfu-suffix errors are common, it’s a built in check to ensure the code your flashing is for that type of device. The other error you will see is a get status error at the end. That’s because the device resets and is no longer in dfu mode so it can’t read the status.

1 Like
6

As far as I can tell, I am on 0.4.3 now, and I am still having I2C problems described above. I’m open to other suggestions.

7

Please update to 0.4.4-rc3 which has I2C fixes and other stability fixes. Thanks! :slight_smile: