No worries got it working now, I had accidentally taken the wrong resistors.
Ok, I’m going to steer this discussion back to the I2C issue…
@mdma, @BDub - I know this is being worked on, but do you guys have an estimated ETA for the fix or at least a proper workaround? I have everything working on my board, and this is the only issue holding it back, so it would be great to get an idea of the timeline if you have any idea…
Thanks in advance.
You can give this a try and see how things go: https://github.com/spark/firmware/commit/09dd8096774c74b6680ddb47b39fc21134df49a8
Not sure if this applies, but, I had an I2C connection problem when trying to add a magnetometer to a 6DOF IMU. I made the wiring as short as possible. The problem went away.
Thanks for the info. The wires on my board are fairly short, so I don’t think that is the issue. Besides, it consistently doesn’t work until I reset the board, which makes me think it is a code issue.
Thanks for this. How can I use this with my code?
For now with fixes, it would be accessible only if you compile locally.
Is there any new progress made? or was it just reversing the change that was made to try and fix the issue? calling
I2C_GenerateSTOP(I2C1, ENABLE); was the “fix” that didn’t work (and made it worse), the original issue is still there…
@Hootie81 there were some changes here: https://github.com/spark/firmware/commit/09dd8096774c74b6680ddb47b39fc21134df49a8
Yeah, unfortunately that doesn’t fix the problem… that was reversing the attempted fix. I’ll continue to debug and see what else I can find… but I’m almost completely out of ideas
@Hootie81 Hey just reaching out to see if I can get some more info from you. Are you still seeing I2C failing with code from the latest
develop branch? Which device and library are you using? If you have a repeatable test pattern, that would be super helpful. Also do you have access to a logic analyzer? I’d be curious to see what is happening before and after it fails. So many questions I know… thanks for your help on this
I will zip up and send you the code I’m using tonight when I get home from work. It seems to happen with all the i2c devices I have, but most noticeable on the mpu6050. I should have taken notes on all the testing I have done so far, I can’t remember what was before and after the stop call was added.
It’s pretty random when it happens sometimes it’s during the first 10 seconds other times it’s after 5mins. I’m reading 2bytes, followed by 42bytes 25times a second… I have also noticed the timing is a bit up and down with when data is read… sometimes it’s 40ms other times it’s 2ms I’ll have more of a look tonight
I’m using 2 sparkfun weather Photon shields with my 2 Photons. Using the Sparkfun example code. One of the libs has a naming error so the examples don’t compile in the web ide. I’m using Particle Dev to compile from the sparkfun repo.
Both i2c sensors report presence, but you may or may not get any valid data from them after that. The bus always dies at some point, usually within a minute or two. I took a quick look with my logic analyzer. Looks pretty normal on the surface then everything just stops, no activity but a periodic clock pulse. This may just be the software giving up after too many errors.
I’ll have some more time to take a closer look this weekend so I can correlate the bus to the software. The weather shield has 10k pull-ups and I see the bus is running at 100k so I wouldn’t expect any problems with this configuration.
I2C has been fixed in the latest release- https://github.com/spark/firmware/releases/
I am still getting the I2C error 998 on a Photon from a HTU21D after few time (never constant), despite I have 0.4.4 firmware, and 4.7K pullups.
The sensor was working perfect on my Core.
Do you know if 0.4.5 fw is still focused on some erratic behaviour on I2C, and when it should released
There are no new fixes for I2C in 0.4.5. Could you try with a smaller pullup to reduce capacitative affect of the bus?
You could try the work-around described over here:
Some users are reporting better-but-not-perfect results by doing this begin/end when there is a problem.
Right now I have just one I2C sensor on the bus… In my Core implementation it was 3 I2C sensors… And I didn’t yet put the Powershield which is also I2C…
@mdma I will try as soon I can get some other resistors to lower the pull-ups…
@bko I will also try the suggested workaround, but not nice to check state of I2C bus all time and then do the suitable (s) Wire.beginTransmission(deviceAddress) with sensors concerned when there are many…
You only apply the work-around when you detect a problem.