Any thoughts on why i2c on a spark core could suddenly stop working? Code was working fine for a couple of months (it’s reading a Chirp moisture sensor). A few days ago, I noticed I was getting garbage data. Testing it now, I’m seeing a Wire.endTransmission return value of “4: data byte transfer timeout”. Considered the possibility that the core was toast, so uploaded the code to a second core and tested using a second sensor - same result.
Core info states: ‘You are building with firmware latest (0.3.4)’
Seemed like pretty straightforward i2c code.
unsigned int readI2CRegister16bit(int addr, int reg) {
Wire.beginTransmission(addr);
Wire.write(reg);
Wire.endTransmission();
delay(20);
Wire.requestFrom(addr, 2);
unsigned int t = Wire.read() << 8;
t = t | Wire.read();
return t;
}
???
@dfreymann, that IS strange! I have to ask - are there pull-up resistors on the I2C lines?
1 Like
@peekay123 Yup, there sure are!
@dfreymann, ok so it has to be a common issue with the code or with the power supply. Did I understand correctly that you tried the code on a second Core/sensor set? Did you use the same power supply to power both?
What about connections to the Chirp? Anything that could cause issues.
Another thing you could do is run the I2C bus scanner app to see if the Chirp shows up (and which address!).
Yeah, OK, more ‘weird’ stuff.
Running the I2C bus scanner was a good idea - with everything hooked up, and the sensor getting power, it reports ‘No I2C devices found’.
I checked the wiring connections (it’s all protoboard) and nothing looked awry, connections all good. For the stuff I’m reporting now, I’m powering via USB with the same cable.
So, I pulled out a new Photon I hadn’t gotten around to yet (I have 4 cores active, and 2 unused photons). Hooked it up to the protoboard and to the sensor. Loaded up the I2C bus scanner…
… finds the sensor I2C address 0x20 just fine.
So, at this point I’m concluding that the circuit connections are good, I guess. And both the original Core and the second Core I was testing seem otherwise to be fine. For example, I have hardware SPI to a display and that was working as expected.
So I’m left with something intrinsic to the code (???) that’s affecting my Cores in some new way?
Or, two busted Cores that otherwise seem to work. Odd.
(Unfortunately, I can’t immediately test the sensor code with the Photon because I’m getting httpclient compilation errors with the Photon 0.4.4 firmware that don’t occur with the Core firmware 0.3.4. Doh!)
1 Like
How about this - since this problem has shut down development of my sensor setup - is there any way to test whether a particular pin is ‘busted’ (non functional) or not? I don’t have any more Cores I can throw at this, so if there’s a diagnostic I could run, or a measurement I could make, that would help.
Any ideas?