SERCOM::startTransmissionWIRE() freezes on hardware issue.

[Jolbas]

I have a problem when using I2c with Wire library. When the SDA signal is disturbed by something then sometimes when the process reaches line 530 in SERCOM.cpp it gets stuck in an infinite loop running SERCOM::startTransmissionWIRE() over and over again. If I add a 1500 µS delay before line 530 it seems to get out of the loop. Its like the hardware do not get time to recover without the delay. But a delay would maybe be bad for performance if it's common for this code to be run.
I have this problem on two MKR GSM 1400. Maybe someone can confirm this on different hardware. If I connect SDA to 3V3 I run into this problem.

Here is the lines around SERCOM.cpp:530 with my fix.

if(!isBusOwnerWIRE())
{
  // Restart communication after small delay
  delayMicroseconds(1500);
  startTransmissionWIRE(address >> 1, flag);
}

I've struck the same issue. The recursion blows the stack when a major hardware issue occurs. As you mentioned your fix just delays the inevitable!

I've come up with something that works for me. I've started with a clone from issue #439 and added a time out (of sorts) to limit the recursion within SERCOM::startTransmissionWIRE() when a hardware issue occurs.

Try replacing your code with the following,
` if(!isBusOwnerWIRE()) {

    if (!timeoutInterval) return false;
    
    if (restartTX_cnt > timeoutInterval) {
        // only allow limited restarts
        restartTX_cnt = 0;
        return false;
    } else {
        // Restart communication after small delay
        delayMicroseconds(1000);
        restartTX_cnt++; // increment restart counter
        // Restart communication
        startTransmissionWIRE(address >> 1, flag);
    }
} else restartTX_cnt = 0;`

and within SERCOM.h change line 231 to,

uint32_t timeoutRef, restartTX_cnt;

PR submitted, but you can checkout branch wire_timeout if you want to test my mods directly.

As an update, from my field testing, I've been running around 5x units continuously for the past couple of months now. All seem to be able to handle and recover from i2c glitches without complete system lockups, of which I was experiencing at least once per week per device previously.

My thanks go to @jrowberg and others for the work that went into the initial time out implementation.

[nmaas87]

I have no time to test or qualify your PR at the moment, but I just wanted to thank you, as I wanted to start using I2C on AT-SAM-D and this will probably save me in the future, so - thanks a lot for your time and effort :)!

No worries Nico, I hope your adventures into I2C land are fruitful and this particular issue won't hold you back! On Friday, 4 September 2020, 4:42:23 pm AEST, Nico Maas <notifications@github.com> wrote: I have no time to test or qualify your PR at the moment, but I just wanted to thank you, as I wanted to start using I2C on AT-SAM-D and this will probably save me in the future, so - thanks a lot for your time and effort :)! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.