TWI recover from timeout

RE: TWI recover from timeout

Ole Bauck — Wed, 30 Mar 2016 09:34:34 GMT

What is the build code of the chip you are using (for example QFACA1)? Could you upload a logic analyzer or oscilloscope capture of the lines right before the twi stops working (when the lines are pulled to ground)?

RE: TWI recover from timeout

AmiguelS — Fri, 18 Mar 2016 13:48:51 GMT

The problem only arises when The SDA/SCL lines are briefly forced to GND, not when left floating. I have ported everything to SDK 11 and performed the same test and the results are the same. When the lines are pulled to ground the module seems to stop working entirely. I have moved on from this test as its a very particular and weird event to occur.

I have been able to confirm the TWI drivers from SDK 11 include a mechanism to report un acknowledge transfers.

RE: TWI recover from timeout

Ole Bauck — Wed, 16 Mar 2016 13:41:45 GMT

What is the device in the other end? If you pull the SDA/SCL lines to GND the twi hardware peripheral will not work. Do you get the same problem if you leave the lines floating all the time?

RE: TWI recover from timeout

AmiguelS — Wed, 16 Mar 2016 10:31:20 GMT

Once the error is introduced (pull SDA/SCL to GND) and detected, the TWI module is re-initialized (including the above mentioned flag clear) and the following happens:

nrf_drv_twi_tx()/nrf_drv_twi_rx() returns NRF_SUCCESS
However, SDA/SCL lines have no transitions, they are completely still
nrf_drv_twi_int_handler() is never called again

Porting to SDK11 is not an option as I need the functionalities offered specifically by SDK10 (S110)

RE: TWI recover from timeout

Ole Bauck — Wed, 16 Mar 2016 09:42:59 GMT

Could be a number of things. Have you monitored the physcal lines with logic analyzer/oscilloscope to see if e.g. the stop condition is issued? Can you check if the nrf_drv_twi_int_handler(..) is called at all? Could you try with SDK 11 to see if this works (you may be able to just port the files)?

RE: TWI recover from timeout

AmiguelS — Wed, 16 Mar 2016 09:15:48 GMT

By using the mentioned line, nrf_drv_twi_tx() and nrf_drv_twi_rx no longer return BUSY, returning NRF_SUCCESS instead. However, communication still fails, as the callback function is never called. The module till seems to be "stuck" in some operation, even though the flag has been cleared. Is there any other operation needed to completely reset the module?

RE: TWI recover from timeout

Ole Bauck — Tue, 15 Mar 2016 17:04:04 GMT

Yes, I was mixing with the local variable is_busy in twi_transfer(..), answer updated.

RE: TWI recover from timeout

AmiguelS — Tue, 15 Mar 2016 15:36:15 GMT

The struct twi_control_block_t in SDK 10 differs from the one in SDK11. Your answer implies the use of the SDK11 struct, as there is no such field as busy in SDK10 twi_control_block_t. The available fields are:

state
substate
transfer_in_progress
transfer

Could the solution be related to setting transfer_in_progress to false?

RE: TWI recover from timeout

Ole Bauck — Tue, 15 Mar 2016 10:33:32 GMT

Problem is that a busy flag in an internal structure is not set to false when initializing the driver. This has been fixed in SDK 11. Either update to SDK 11 or add this line to nrf_drv_twi_init(..):

m_cb[p_instance->instance_id].transfer_in_progress = false;