I2C unstable

[Steven Boonstoppel]

@Brian-Wyld thanks for your response!
I did not have them installed, but I just tried both 4.7k and 10k pull-up on SCL/SDA but it did not solve my problems. I2C bus still fails after successful SSD1306 initialization.. :( (and i2c.scan() still lists all addresses present)

[Brian Wyld]

@Steven-Boonstoppel
Did you try swapping the SSD1306 between a 'good' and 'bad' unit? it only takes 1 misbehving I2C module to ruin the party for everyone...

[Steven Boonstoppel]

@Brian-Wyld all modules have been swapped. Disconnecting and removing the SSD1306 from software makes the LoPy stumble on the BME680 still. Disconnecting and commenting out the BME680 makes the LoPy trip on the VEML6070.. all the while happily showing their addresses each time, proving that the cables and connections are (somewhat) working and I2C is (somewhat) correctly initialized.

[robert-hh]

@Steven-Boonstoppel scan() is not overly demanding for the communication, since only the address byte is sent and the ACK/NAK state for this byte is used to tell, whether a device is present. I have seen it that scan() worked, but data transfer failed.
But in your test: did you only remove the devices by software? That's not sufficient, if it is a hardware problem. You have also to disconnect the devices from the I2C bus.

[Steven Boonstoppel]

@robert-hh I have done a lot of trial and error the past two hours. There's now a very interesting situation on one of the nodes:
a) All works fine when scanning for the addresses first.
b) All fails when performing no address scan.

That's literally it... how...

[robert-hh]

@Steven-Boonstoppel That's strange. scan() is stateless. The only difference I see in the code is by the I2C ID, being <2 or >= 2. Which I2C device do you use?

[Steven Boonstoppel]

@robert-hh I am sorry - I don't understand what you mean by I2C ID being <2 or >=2.
I am using LoPy4's default I2C(0) as master at 100 kHz, using pins 9 and 10.

[jcaron]

@Steven-Boonstoppel Is there any other code running on the LoPy which could use I2C and change the I2C device configuration (pins, etc.)?

For instance if you have code to handle stuff for the PySense/PyTrack/PyScan (to detect their presence for instance) it would use I2C device 0 with pins P22/P21 rather than the default 9 and 10.

[robert-hh]

@Steven-Boonstoppel So the ID is 0.

[Steven Boonstoppel]

@jcaron nope, nothing. Full code is available at https://github.com/StevenCellist/MJLO/tree/main/software.

[jcaron]

@Steven-Boonstoppel Is Pybytes disabled? How are you powering the board? Maybe you have a current spike related to all the sensors starting up at the same time? Monitoring input current and voltage during the awake cycle may be interesting.

[Steven Boonstoppel]

@jcaron Pybytes is disabled, powering over USB (tried battery and both as well). Current spike happens when the voltage regulator to SDS011 and MQ135 is enabled which happens after all I2C sensors have been used. Until then the regulator is in shutdown mode.

[jcaron]

@Steven-Boonstoppel what’s the max total current used? What’s the USB power source? Is the USB cable adequate? What kind of battery?

Just trying to eliminate a possibility…

[Steven Boonstoppel]

@jcaron during I2C activity below 150 mA, when enabling the voltage regulator after that there's a minimal peak up to 1A for a few milliseconds and then about 500 mA. USB cable is of great quality and has never been a cause for troubles. Power source is my laptop during these debug sessions. Battery is a 26650 Keeppower 5200mAh Li-ion.

[jcaron]

@Steven-Boonstoppel have you confirmed in your testing if the culprit is the LoPy or the expansion board (or the breadboard)?

Can you confirm the voltage at idle on the two lines? Possibly at different places along the bus (I.e. at each of the devices).

BTW, it the physical layout actually close to a bus or closer to a star?

Are all devices powered at the same voltage?

[Steven Boonstoppel]

@jcaron I have fiddled around more and more using your questions and came to this conclusion: one of the solder points on the SSD1306 was not completely right. This mostly manifested when cables were bent differently, but must have also thrown problems when the bus was being used for other sensors somehow. The exact reason as to why i2c.scan() had an extremely high correlation with the display working - I don't know. Electricity is weird.

Other nodes that had I2C problems also suffered mostly from badly soldered contact points, and it seems like all problems have been resolved now. Thanks for the patience and questions as it ultimately led me to the real culprit.

Case closed - lesson learned: always check your contact points even if it works.