Reset I2C port?

[stephenf7072]

Subject of the issue

Reset an Artemis I2C port from software without doing a full uC reset

Your workbench

Artemis Nano and custom board, with BME280, AS726X and others on I2C(2).

Steps to reproduce

Sometimes when the AS726X (using the Sparkfun library ) is not present, or is plugged/unplugged during use, the bus no longer works for the other devices, even after sleeps, .end(), .begin() calls, etc. It's a bit random and hard to track down or replicate, although I've made some changes to help the AS726X library deal better with errors, pull request on that is here: https://github.com/sparkfun/SparkFun_AS726X_Arduino_Library/pull/2

It's a twoWire object, and I tried both global and local declarations, didn't seem to help.

So for now, I'm happy to detect the I2C bus error and just reset it - the question is, how?

Expected behaviour

N/A

Actual behaviour

N/A

[nseidle]

I don't know that I've hit a locked up I2C hardware instance but I've heard stories on other platforms so I support adding some sort of method. We've got an end() method that deinits, and powers down the I2C hardware. That should be sufficient, no?

I know you say it's random, but do you have any way of causing a hangup so we can test?

[stephenf7072]

Unfortunately I've been calling the twoWire::end() method in the go to sleep function but it doesn't seem to help recover the I2C bus (but a full reset fixes all).

The hangups are triggered by a peripheral device being absent, or being unplugged. Not always in the same scenario. It's also on my custom (cave logger) board running a bunch of my complex code with lots of peripherals (at least 2 per I2C bus). I've tried, but not had any luck with replicating on a stock board with stock peripherals. So I'm not expecting too much sympathy or help, but maybe by flagging it someone else will have had a related experience..

I guess next chance I get, I'll have a poke in the deinitialize() function and at least see what's happening. I hadn't delved quite that deep yet.

[stephenf7072]

I still didn't have much luck with getting to the root of this problem, but have bypassed it by writing the current state to flash/SDcard and then doing a software reset and full re-init (using the saved state details to resume whatever was happening).

The resets are the subject of a new Example8 in pull request #237

Some more context here:
https://forum.sparkfun.com/viewtopic.php?f=169&t=52431&p=217445#p217445

[Wenn0101]

@stephenf7072 I am looking back thru a couple of these issues that haven't had movement in a while. Do you still have an issue with this in the latest version?

I may try to look back at this if I have some spare cycles and verify if the problem still exists.

[stephenf7072]

I haven't looked at it or had issues since my workaround, and haven't got to tackling the new core version beyond a brief won't-compile foray. Given that and there are probably more important things to be working on, I'll close this issue.