Timeout handling with nrfx_twi driver

[dzabel]

Hi,

I am searching for a clean way to handle a timeout (because I2c device does not respond or there is a hw issue with the I2c bus).

On startup I probe different I2c sensors. I am using the nrfx_twi driver. When I use the nrfx_twi_tx function in blocking mode, I get NRFX_ERROR_INTERNAL, because a timeout has occurred within the twi_tx_start_transfer() function. And the busy-flag contained in the twi_control_block gets cleared on exit of the nrfx_twi_xfer() function, so next time I call the nrfx_twi_tx function to probe the next sensor, all is well. But If I want to use the driver in non-blocking mode, I get a problem. There is no timeout in this case, and I have to provide that by myself. But I don't see a good, clean way to stop the ongoing transmission after my code detects a timeout. First I tried to call nrfx_twi_disable() and nrfx_twi_enable() again, which seems to stop the transmission, but the problem is, that the busy flag does not get cleared. So the next call to nrfx_twi_tx() fails with NRFX_ERROR_BUSY. The only way around this seems to be to call nrfx_twi_uninit() and nrfx_twi_init(), which includes de-initialization and initialization of the gpio pins, which I don't want here.

My question is, if there is a better way to abort a transfer when using non-blocking mode?

Regards

  Dirk

[Kenneth]

My question is, if there is a better way to abort a transfer when using non-blocking mode?

Not really no, I guess it is always possible to manipulate the busy flag also, but at the end this will be very application specific on how you want to recover and handle this situation, so I don't really have any good suggestion than to uninit() and init(). If you are using external pull-up resistors I think that should be fine.