I’m testing out the Photon now with firmware 0.4.7 and the issue on the Photon is that after a few loops, most times as few as just one loop, the Photon “hangs” with the observable behavior being a solid green/cyan LED (the same color as WiFi, except without “breathing”).
The main commonality, so far, seems to be it stops working when accessing I2C components via the Wire functions.
Given that the Photon typically gets through the first loop without too much issue, I’m sort of at a loss why it’s getting stuck on subsequent runs.
Just an update to this thread, I’ve tested a back-ported version of the same code on a Core and the software works just fine when I build using firmware 0.3.4 – the problem seems to be rooted in the 0.4.x versions.
The RUSK2 board definitely has 4.7K pull ups on both SCL and SDA. If you can tell me how or what to check with the debug #defines I’ll be happy to chase that down. Sorry, about my limited experience in these matters.
I did a quick search for “debug” and debug in the source files but didn’t find anything to work with offhand ;).
@marcusuy I’m not sure why you are scanning for I2C devices on every loop without doing anything with the info, but that might be buggering up the bus. Try commenting this out:
Also each sensor (and you have a lot of them) has a library in which it seems each time through the loop() when a sensor is read, the library is constructed on the fly, used and then because it’s in a local function scope is deconstructed automatically at the end of the function. I did not look at the deconstructors to see what they do but this might be leading to problems. To keep it simple for debugging, move them into a global scope and see if that helps… and maybe leave them there if there is no strong desire to allocate/deallocate these on the fly.
Just an update: My original issue, the one that prompted this thread, is fixed on the Core and Photon using firmware version 0.4.9 – quick question, what in the I2C implementation was changed?