I2C gets stuck with -EBUSY if i2c_* function calls timeout on zephyr (NCS) for nRF52840

[Leowt]

To reproduce this problemm Ive added a device to the I2C that does not respond to a read command.

The `i2c_read` call first returns `-EOI` (-5) and for every other i2c funcion calls it will return `-EBUSY` (-16).

Apparently it locks the i2c subsystem, a `sys_reboot` makes the i2c BUS available again.

I wonder if this is a known issue, and if there is a way of recovering the i2c subsystem? `i2c_recover_bus` is useless for this effect.



a similar issues were posted here:

- https://devzone.nordicsemi.com/f/nordic-q-a/70481/what-means-errno--16-for-nrf52832/289628 
- https://devzone.nordicsemi.com/f/nordic-q-a/66928/zephyr-i2c-locked-into-ebusy

[Kenneth]

Hi,

Do you have a logic analyzer trace? Typically if you get a busy you should retry, so I am wondering does it fail when retrying? Is there any difference depending on the delay between calling i2c_read()?

Do you have the exact error codes from nrfx_twim_xfer() as asked for here:
https://devzone.nordicsemi.com/f/nordic-q-a/70481/what-means-errno--16-for-nrf52832/289628#289628

Do you see the same if no device is connected to the i2c bus? 

Kenneth

[Leowt]

This issue gets the bus stuck after the first failure.
I can confirm that if I remove the device from the bus physically (no devices connected to the bus), it still returns me -EBUSY for any i2c_* call.
Im not sure the logic analyser is of any help since I know that what triggers it is the target device not responding (timeout) for this case in particular and it persists after I disconnect the device from the BUS (no other device is connected), and the only way I could see to get the bus back to a usable state is to call a sys_reboot, because it gets stuck at -EBUSY indefinitely.

I verified myself that:
- The first -EOI error comes from here https://github.com/nrfconnect/sdk-zephyr/blob/d5fe6f2e7f5ba28c9637297368ab1d3ecce7183c/drivers/i2c/i2c_nrfx_twim.c#L145
- All the following -EBUSY errors come from here: github.com/.../i2c_nrfx_twim.c

[Kenneth]

Thanks for the clarification, I thought you meant by "every other" that it happened once every two transfers.

A logic analyzer trace could still be useful just to check where the NAK (I assume) exactly occurs during the I2C transfer here. The only explanation I can find is that event_handler() in i2c_nrfx_twim.c never fires, due to twim_irq_handler() did not fire in nrfx_twim.c, but I don't have an explanation to that. Are you able to find out a bit more by debugging or adding a logic analyzer trace:
https://github.com/nrfconnect/sdk-hal_nordic/blob/8f013ea950f41bf69b18bf688bfb0dd80a3fdc44/nrfx/drivers/src/nrfx_twim.c#L650 

[Leowt]

Im sorry, I posted the wrong links, Im using twi not twim. (Ive tried TWIM but same issue happens)

For reference, the following are the correct links:
- The first -EOI error comes from here: https://github.com/nrfconnect/sdk-zephyr/blob/d5fe6f2e7f5ba28c9637297368ab1d3ecce7183c/drivers/i2c/i2c_nrfx_twi.c#L127 
- All the following -EBUSY errors come from here: https://github.com/nrfconnect/sdk-zephyr/blob/d5fe6f2e7f5ba28c9637297368ab1d3ecce7183c/drivers/i2c/i2c_nrfx_twi.c#L106 

Ill try to get a logic analyser up and running soon