Application firmware hangs up in twi_wait() function

RE: Application firmware hangs up in twi_wait() function

Kenneth — Fri, 29 Apr 2016 10:25:51 GMT

Do you have some traces from a logic analyzer?

I believe you have multiple error conditions here which you are not handling gracefully in your application code:

A twi slave might NACK the transaction if it's not ready, this will cause a twi error. Add a delay and try again.
A twi sensor can delay an twi transaction by "clock stretching" if it's not ready. This might cause the transaction to be busy or not complete if you call a new transaction before the previous transaction is complete. Make sure not not call a new twi transaction before the previous is finished.
The execution of a twi transacation might be delayed by other processes. This should not be a problem, just add a delay and try again.
The driver does not make a copy of the supplied parameters internally, so if you update any of the buffers before the previous twi transaction is complete, this might not work well. Make sure not to update any of the buffers before the previous transacation is complete.

All the above can cause a problem if the application does not differentiate the different error conditions that might occur. Also check the datasheet of the twi slave on timing details that might apply.

During debugging it might also make sense to update the driver to the latest version for possible bug fixes that might apply.

RE: Application firmware hangs up in twi_wait() function

Andreas — Thu, 28 Apr 2016 14:00:40 GMT

Image (cross referenced from a comment)

RE: Application firmware hangs up in twi_wait() function

Andreas — Thu, 28 Apr 2016 13:59:00 GMT

Hello Kenneth, I tried it that way:

do
{
	res = nrf_drv_twi_tx(&m_twi_eeprom, EEPROM_HW_ADDR, m_address, 2, true);
	if(res == NRF_SUCCESS) break;
}while(res != NRF_SUCCESS);

But than, the operation will hang up again in that while loop. This while loop will never be done, because res will not become NRF_SUCCESS anymore. I have an idea why that my happens. I will attach a sketch in another answer. Unfortunately it is not possible to add images to a comment. Is it possible that there is a problem, if two processes (application and softdevice-process are using the TWI BUS). I will try to implement some kind of a MUTEX for that behavior. But this will be very complicated, because the "normal" application process can be interrupted by an BLE event anytime. And I have no idea how it is possible, to wait for the completion of an TWI operation that is running in the normal application process. I hope the sketch and my explanation is clear enough, to understand the problem. Regards

RE: Application firmware hangs up in twi_wait() function

Kenneth — Wed, 27 Apr 2016 12:52:34 GMT

But wouldn't that loop execute very fast? I think you should add a delay for each iteration so you have some control on how fast that loop execute.

RE: Application firmware hangs up in twi_wait() function

Andreas — Wed, 27 Apr 2016 11:17:57 GMT

Hello Kenneth, sorry, but there must be something different. For testing I implemented it like this:

for(retries = 0; retries < 250; retries++)
{
	res = nrf_drv_twi_tx(&m_twi_eeprom, EEPROM_HW_ADDR, m_address, 2, true);
	if(res == NRF_SUCCESS) break;
}

But I still reach the 250 retries. And for me it does not look liker there is any improvement. Thanks for spending the time and helping solving these open issues. I believe, if I would implement it with a while loop, the software would hang up again. Then it is the same behaviout than with the event handler solution...

RE: Application firmware hangs up in twi_wait() function

Kenneth — Wed, 27 Apr 2016 10:14:06 GMT

Retry until NRF_SUCCESS is fine.

RE: Application firmware hangs up in twi_wait() function

Andreas — Wed, 27 Apr 2016 09:37:58 GMT

Hello Kenneth, sorry for that mistake. Of course, res will be one every time if it is bool... I changed it to ret_code_t. Now I get NRF_ERROR_BUSY, as return value from nrf_drv_twi_tx(). Is it a possible solution to only wait and try the transfer again? BR

RE: Application firmware hangs up in twi_wait() function

Kenneth — Wed, 27 Apr 2016 09:07:21 GMT

You should modify:

  //bool res;
  ret_code_t res;

Then most likely you will see it return the correct error code, but I am not sure why the compiler doesn't return a warning when it cast an uint32_t to bool.

RE: Application firmware hangs up in twi_wait() function

Andreas — Tue, 26 Apr 2016 12:53:29 GMT

Hello Kenneth, interesting, I can confirm, that I do not get the error if I slow down the function which causes very much I2C transfers per second in background. My EEPROM_write() function where I get the error looks like this:

res = nrf_drv_twi_tx(&m_twi_eeprom, EEPROM_HW_ADDR, m_address, 2, true);
if(res==NRF_SUCCESS){
...
}
else
{
dbg_printf("Error transmitting I2C read address %d!\r", res);
return NRF_DRV_TWI_ERROR;
}

and the output I get on the terminal looks like this: Error transmitting I2C read address 1! So for me it is clear that I get the error value 1 from nrf_drv_twi_tx()

RE: Application firmware hangs up in twi_wait() function

Kenneth — Tue, 26 Apr 2016 12:34:38 GMT

I am not sure what is the problem here, but I can't find that nrf_drv_twi_tx() can return NRF_ERROR_SVC_HANDLER_MISSING error code. I searched for NRF_ERROR_SVC_HANDLER_MISSING in the twi source code in nRF5 SDK v11 - \examples\peripheral\twi_master_using_app_twi.

RE: Application firmware hangs up in twi_wait() function

Andreas — Tue, 26 Apr 2016 07:32:24 GMT

Hello Kenneth, I changed my TWI driver initialisation and set the event handler to NULL. Now the application does not hang up any more. But I still get error 1 (NRF_ERROR_SVC_HANDLER_MISSING) sometimes from the nrf_drv_twi_tx() function call. How to go on with that? I think this breaks down my BLE data transmission... BR

RE: Application firmware hangs up in twi_wait() function

Kenneth — Mon, 25 Apr 2016 10:57:00 GMT

Likely there is a race condition of some sort, where you try to start the next transmission at the same time as the previous one is done. Have you considered using the driver in blocking mode without a callback registered? E.g. init nrf_drv_twi_init() with NULL as the event_handler(). Then each call to nrf_drv_twi_tx() is blocking, and you don't need to use twi_wait() between calls. The nrf_drv_twi_tx() will return when the twi operation is complete, with either NRF_SUCCESS or NRF_ERROR_INTERNAL return value for the executed twi operation.

RE: Application firmware hangs up in twi_wait() function

Andreas — Thu, 21 Apr 2016 14:14:19 GMT

Another point. I can see, this error happens only, if there is a high payload in the TWI bus --> 300-400 calls per second. If I switch OFF the function which causes these calls, the error seems not to happen anymore. How to handle this? Regards

RE: Application firmware hangs up in twi_wait() function

Andreas — Thu, 21 Apr 2016 13:10:48 GMT

Hello Kenneth I changed my twi_wait function a little bit to:

void twi_wait(void){
uint32_t count1 = 0, count2 = 0;
uint32_t retval = NRF_ERROR_TIMEOUT;
for(count1 = 0; count1<50; count1++)
{
	for(count2 = 0; count2 < 10000; count2++)
	{
		__nop();
		if(m_xfer_done)
		{
			retval = NRF_SUCCESS;
			break;
		}
	}
	if(m_xfer_done) break;
}
if(retval != NRF_SUCCESS) dbg_printf("twi_wait error\r");}

Now I can see where it is going wrong. It breaks when trying to transmitt a read address to the EEPROM. nrf_drv_twi_tx() returns 1. Is that helpful anyway? With the new twi_wait() function, of course my firmware does not hang up. But the problem is still alive... Unfortunately I have no logic analyzer. Only a oscilloscope. And it is pretty hard to trigger to that mistake.

BTW: I know that support for PACK is deprecated. This is the next point on my list, to switch from PACK to SDK. But before doing such a step, I want to have a stable firmware.

RE: Application firmware hangs up in twi_wait() function

Kenneth — Thu, 21 Apr 2016 10:28:44 GMT

Hi, I can't find any examples out of the box with both BLE and TWI at the moment. I think what would help here is if you have access to a logic analyzer so you can see what occurs on the serial interface. Also it might help to debug the events in twi_handler() for NRF_DRV_TWI_RX_DONE, NRF_DRV_TWI_TX_DONE, and NRF_DRV_TWI_ERROR. You should ensure that application interrupt priorities is set according to the softdevice specification document.

FYI: We are no longer maintaining pack, so you should download the latest nRF5 SDK in zip format.

RE: Application firmware hangs up in twi_wait() function

Andreas — Thu, 21 Apr 2016 09:55:07 GMT

I am just on ivestigating that problem. My idea why that happens is: If the priority of TWI is High, it has the same prio than the Sofdevice. Now, if the transfer rate on BLE is high, but the softdevice is "waiting" for the result from another characteristic call, it comes to some kind of a dead loop. Is that right!? But how to avoid this? I tried to add a twi_wait in the BLE on_write() function. But that doesn`t help. With that change, the firmware hangs up in this while loop (in the on_write function). Regards!