Caught in I2C busy loop

[DeppLearning]

Hey there,

I'm running into a busy loop in the I2C bus here. The problem occurs only rarely and randomly, sometimes it takes several hours (amounting to thousands of I2C interactions) until my program gets caught in that loop.

My Boards are ESP32-S3-Box-3 devices, I yet have to verify the same problem occurs on an ESP32-S3-DevKit. The I2C device is an Atecc608x chip, I've been using the Adafruit Atecc 608a breakout boards, but also Atecc608B boards, they all seem to have the problem. For the driver, I'm using this. I've seen the problem to occur in the sign and digest commands, it's always the same while loop in esp-hal where I get caught.

There is known I2C problems with the "A" variant of the chip, that are supposed to be fixed with the "B" variant. However, those problems should affect other devices on the i2c bus, I'm using the atecc on it's own I2C bus with no other devices. I am using other I2C devices simultaneously (on another I2C bus) of the ESP-32-S3-Box-3, i.e. gyro/temp sensor and touch screen controller but I am not seeing this problem there.

When I try to just break out of that empty loop after feeling like I got stuck, I'll get an error that I can handle in my program by resetting the chip (I didn't connect the atecc to 3v3 but to a gpio pin that I turn off in that situation) and eventually recover from the situation (i.e. keep signing/digesting using the chip):

            let mut n = 0;
            //second while loop
            while !self
                .register_block()
                .int_raw()
                .read()
                .txfifo_wm()
                .bit_is_set()
            {
                n += 1;
                
                if n >= 1000000 {
                    // returning error doesn't work, I'll get stuck elsewhere (not sure where)
                    // return Err(Error::TimeOut);


                    // trying to clear the interrupt bits again doesn't works either
                    //  self.register_block()
                    // .int_clr()
                    // .write(|w| w.txfifo_wm().clear_bit_by_one());
                    
                    break;
                }
            }

Is this a bug in esp-hal? Could I have done something to prevent this in software? I'm on commit fb90fe7

[bjoernQ]

I think looping there forever isn't a good thing definitely. At least checking the errors from int_raw should be done there and in case of an error we should immediately return the error.

There are probably situations where we cannot recover from the error just by software however - then it needs your approach of restarting/resetting the device - but at least we should give a clear indication of an error