Handling I2C bus errors

There is a post from 7 years’ ago that really is out of date on this topic.

I am seeing some problems with USB cables used to carry the I2C bus to peripheral devices. If there are connectivity issues with the individual lines (D+ and D-) of the USB cable carrying SDA and SCL then the commands sent from the Photon to a peripheral GPIO expander do not get implemented. This is failing silently at the moment. I would like to implement some sort of error monitoring/reporting and potentially a restart for the I2C bus. Clearly, if the line is broken then this needs to be fixed. At the moment I am seeing a few intermittent problems, not very common but difficult to diagnose remotely!

From the documentation it appears that the only way to do this is to monitor the result value from Wire.endTransmission(); and if the result != 0 then log a problem has occurred and call Wire.reset();

There is no example in the documentation about such error recovery. Can anyone propose a better approach than the simple one above? Thanks

I’ll strongly recommend to do not use usb cable D+ and D- to carry i2c communications as they are twisted and designed to work with differential signals.
I2C was implemented to work with devices on the same PCB, however this doesn’t mean that you can’t run it through wires connection as is already running in HDMI but in HDMI the data wires are running close to each other they are not twisted and the shield is around all wires. Here is a lot of things which could go wrong noises vibrations capacitance between wires etc. Here’s a really good explanation: cables - Is there any benefit to using twisted pair for short-distance I2C? - Electrical Engineering Stack Exchange

I know that I didn’t answer you question but maybe with different type of wires you can achieve lower level of errors or even get rid of them completely



I appreciate your answer. There are several reasons why USB cables are being used over custom cables; cost and availability of connectors and cables. There is ESD protection and the cables used have shielding (some USB cables don’t). Also, VBUS and D+ are used for SCL and SDA not D+ and D- as I wrote. This was an idea to avoid the twisted pair issue mentioned in the article. The problems experienced haven’t been from noise but rather the cables breaking or the odd duff cable not being picked up in production/assembly. The article does suggest 0.5m length cable should be fine and that has been our experience with about 2000 devices in the field.