I2C hangs when power removed from bus on nrf52840

[furbrain]

CircuitPython version

8.1.0-beta.1-44
(Running on a Seeed XIAO nrf52840 Sense)

Code/REPL

import board
import busio
import time
from adafruit_lsm6ds.lsm6ds3 import LSM6DS3
import digitalio

# board.IMU_PWR provides the power to both the LSM6DS3 chip and also the pullups to the I2C bus
pwr = digitalio.DigitalInOut(board.IMU_PWR)
pwr.switch_to_output(True)
print("Starting")
time.sleep(5)
print("Connecting to IMU")
with busio.I2C(scl=board.IMU_SCL, sda=board.IMU_SDA) as i2c_bus:
    imu = LSM6DS3(i2c_bus, address=0x6A)
    print("This works")
    print(imu.acceleration)
    time.sleep(1)
    pwr.switch_to_output(False)
    print("This crashes")
    print(imu.acceleration)
    print("We don't get here")

Behavior

The code above gets as far as the second print(imu.acceleration) and then the device hangs and can only be recovered by a manual reset.

Description

No response

Additional information

Debugging with STLINK-V2 identifies that the call to nrfx_twim_xfer in common_hal_busio_i2c_write is where the device hangs

[DJDevon3]

Could this be related to the warning about not using one of the SPI periphs while on battery power detailed here? I know that's SPI and your issue is I2C but seems similar enough to bring up.

[furbrain]

@DJDevon3 I don't think so. This issue only occurs when the I2C bus pull-ups are unpowered - this leaves both SDA and SCL low (which is an invalid state for I2C). It also affects both TWIM peripherals, whereas the one you reference only affects SPIM3. Also this bug occurs both when battery and USB powered.

[dhalbert]

@furbrain Sorry for the on-again off-again approval/revert of your #8094 PR. I realized this is another manifestation of an old issue, #2253. Rather than look for good initial conditions (which might change out from under us), I think adding a timeout, as suggested in #2253, would be a better solution, since a bad I2C device can hang the bus while a transaction is in progress.

[furbrain]

Yes, I think that could work, but would need to change to a callback related method. I disagree with the comment about the timeout not getting called in #2253 - could have the callback set a flag and then poll for this flag while checking the time and abort if the time increases by a certain amount before the flag is set.

I'd be happy to look at this, though I have found a different route around this problem in my use case in any event.

[furbrain]

My main issue in doing this would be working out a good way to test that I haven't broken any I2C functionality.