I’m also having trouble with Wire code (trying to read an Adafruit BMP180 and TSL2561 over i2c) that was working last month. I’ve traced it to the very first Wire.requestFrom (when initializing my i2c slave device) never making anything available to read. My own code (mostly cobbled together examples) doesn’t work, and neither does this (much simpler and easier to read and troubleshoot) example from @BDubhttps://gist.github.com/technobly/8342329
@Jeff_Highsmith Yes, many of the I2C polling examples do not work. There was an update merged into the build to improve I2C speed using DMA, however that seems to have broken traditional ways of reading data from the I2C bus. There is another thread discussing the topic -
I have been told the plan is to release a fix in the next release on or around Oct 15. Till then if you want to get it working you will have to build locally with a version that has the code fix from @satishgn.
I think I have a similar issue but the symptom is no cloud connectivity; would that make sense? My code worked fine a couple of weeks ago but now, after re-flash, I get no connectivity. If I flash with a simpler non I2C app using web IDE, the core works fine. Any input would be great before I lose it!!
This produces no level change on D0 or D1 (as verified with a 'scope).
P.S. I tried the above earlier this (15 October) evening, so I’m hoping that just means they went with the latter option in the “on or around” part of the release date. If not, I have some other problem.
Can anyone comment on whether it is possible to damage the Spark Core hardware in such a way that digitalWrite() on D0 and D1 work, but I2C doesn’t?
I’ve just got to try online code again. It works not but it is dramaticaly less reliable for me. I2C display with new code failed about 3 times in 9 minutes of code working, stoping all firmware (temperature readings stopped as well). @satishgn@Dave@zachary
Thanks for the heads up, just wanted to say that we saw this and the firmware team is looking into it. Sorry it doesn’t seem to be behaving as expected. You definitely changed your code and recompiled?
@ryotsuke is the display the only thing on the I2C bus? If so can you tell me what display / backpack it is and also would you be able to see if when isolating and running just the display code if this still exhibits the same failure rate?
When you say it failed and stopped all firmware… is there any more to the failure description that you can elaborate on? The observed failure is just that the code “locks up” essentially or is there more to it?