I have an application which uses the S132 softdevice and communicates with a DAC over I2C. The twi is in non-blocking mode. Furthermore, there is a significant delay between nrf_drv_twi_tx calls which should allow the first transfer to complete before the second is started. However, occasionally I get an NRF_ERROR_BUSY return from nrf_drv_twi_tx. I attempted to retry the nrf_drv_twi_tx call in a loop but it apparently never got anything back from nrf_drv_twi_tx other than NRF_ERROR_BUSY as it stayed in the loop.
I then added code to the loop to reset the twi by calling in order: nrf_drv_twi_uninit, nrf_drv_twi_init, nrf_drv_twi_enable before attempting to retry nrf_drv_twi_tx. This does work as a workaround with the output of the DAC changing a few tens of microseconds later than expected but within a tolerable range.
The question that then comes out of all this is how did the twi get stuck so that it remained busy until completely reset?
