Problem with Wire.h - rebooting core

Code on github

Apparently core wont boot if it expects some Wire address to exist and it is disconnected
If it exists I get infinite reboots when connecting to cloud

Could you help in locating the problem for both issues?

I’ve modified R/W to following

void LTC2990::writeRegister(uint8_t r, uint8_t val) {
Wire.beginTransmission(_addr>>1);
Wire.write(r);
Wire.write(val);
Wire.endTransmission(true);
}
uint8_t LTC2990::readRegister(uint8_t r) {
Wire.beginTransmission(_addr>>1);
Wire.write(r);
Wire.endTransmission(false);
if(Wire.requestFrom(_addr>>1, 1, true) >= 1) {
    uint8_t result = Wire.read();
    return result;
};
return 0;
}

This looks pretty fool-proof, but core dies anyway. I’m now reading with delay(5000) as well, that is not helping either.
If i2c device connected it goes in “connect-to cloud-reboot” cycle
If not connected - glows blue led and does nothing

The glowing blue LED means it is connected.

Right now I2C is pretty shaky on the Core. I’m still in the process of rewriting it to take full advantage of DMA.

One thing you should be aware of is that no data is transmitted until you call Wire.endTransmission which isn’t how it works on Arduino. Adding delay(5000) would only make things worse, as it would cause the Core to disconnect from the Cloud. (Your main loop can’t be any longer than around 10 seconds or so.)

As I said in the other thread, don’t shift the address in your code, instead shift it yourself and use the 7-Bit address directly. (Initially the Core wasn’t adding the R/W bit to the end of an I2C address, so I submitted a patch to fix it, however, trying to shift an 8-Bit address in the beginTransmission function call could have some unforeseen consequences, so stick with what you know works, which is a real 7-Bit address: 0b1001100 in hex => 0x4C.)

I don’t see why I cant use bit shift. Simple math operations break spark core? There is no difference between 0x98>>1 and 0x4C, but first one is less confusing to code reader as uses datasheet address, not magic value.

I mean D7 LED. It is unresponsive to cloud in this state.

I’ve currently managed to run code successfully on Arduino with some adjustments. Arduino is not becoming dead when i2c device gets disconnected, so debugging is much easier.

I’ve updated gist to match perfectly working Arduino version. Will test in a while

What I’m telling you is to use 0x4C while you’re testing to remove one variable from the equation.

The compiler isn’t performing your bit shift operation on that argument until it gets to the low level I2C function call in charge of setting the address register.

In my testing back when I fixed the 7-bit addressing issue, entering an address like you’re doing it could cause things not to work.

So instead of arguing with me about it, why not just use the 7-bit address until you get it working, then go back to your way.

Are you familiar with Occam’s razor? :wink: