nrf I2C hang

[dhalbert]

If an nRF I2C (TWIM) peripheral is connected to pullups that are not pulled up, and then connected to an unpowered device, the peripheral can be initialized, but then operations on the bus may hang.

First noted on Arduino Nano 33 BLE. It has an on-board accelerometer. The I2C pullups and the device are both powered from other pins, so they can be shut off when not in use. If the pullups and the device are unpowered, we can still create a busio.I2C(), because it passes the tests that try to detect whether pullups are connected, but then trying to read from the device will hang CircuitPython.

This can be simulated on a Feather nRF52840 by putting a 10K resistor between SCL and SDA and then connecting an unpowered device (I used an LIS3DH) to SCL and SDA. EDIT in 2024: I could not get that to work, but a simpler way is to start using a powered LIS3DH device and then disconnect the power.

Trying to readfrom_into() hangs the code in a busy-wait loop:

https://github.com/adafruit/nrfx/blob/8935519a689c88962b84c661ac606e555898b81a/drivers/src/nrfx_twim.c#L459

        while (!nrf_twim_event_check(p_twim, evt_to_wait))

Some possible solutions are:

1. Improve how to check for proper pullups: maybe try using internal pullups and pulldowns. This doesn't solve the problem of losing pullup power later, for instance.
2. Add a timeout of some kind to nrf_twim_event_check(), directly, or as a background task.

What might be a good timeout (several seconds??), and should it be specifiable in the I2C constructor?

We are using the synchronous TWIM driver, but going to the async driver would not help, I think, because the IRQ handler is not going to get called. So we still need to implement a timeout mechanism. The current Arduino BSP for nRF52 uses the async driver, but it still busy waits and I think it may have the same problem.

Need to decide how much effort to expend to fix this vs. just documenting it.

Tagging @ladyada who discovered this issue.

[dhalbert]

The primary problem for @ladyada was that if code.py got into this state quickly, it seemed impossible to get into safe mode. Perhaps we just need an easier way to get into safe mode. Or perhaps pressing reset during certain operations might initiate automatic safe mode (e.g., set a flag before I2C operations and unset it when done; the flags indicates one should reset into safe mode and not restart).

[ladyada]

yes improved safemode would be great...
but also lets have a timeout of 1 second, that's forever in i2c bus time :)

[tannewt]

@ladyada Did you try the slow double tap to get into safe mode? CircuitPython should wait 700ms on start up to see if a reset occurs and then enter safe mode if it does. Its the same trick as the bootloader, just a wait after the bootloader's wait.

[ladyada]

i tried but was not successful - i probably didnt have the timing right

[dhalbert]

Related to #2635. Deferring until after 5.0.0.