Application firmware hangs up in twi_wait() function

[Andreas]

Hello

I`m using the NORDIC nrf_drv_twi driver implementation from the PACK environment (version equivalent to SDK 8.1.0). Together with the S120 softdevice. If there is an active ble connection, somtimes the firmware hangs up in the twi_wait() function.

void twi_wait(void){
	do
	{
			__WFE();
	}while(m_xfer_done == false);}

Is there any known issue about priority problems or something like this, that could cause such a behaviour? The twi driver runs on APP_IRQ_PRIORITY_HIGH. If I set this priority to APP_IRQ_PRIORITY_LOW, the twi implementation completly wont work, if there is an active BLE connection. So I try to read out some data from the device via ble. This doesn`t even work, if the priority is set to LOW. If the priority is set to HIGH, it works, but sometimes the firmware hangs up in the twi_wait function. Any ideas?

Regards, BTprogrammer

[Kenneth]

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.

[Andreas]

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.

[Andreas]

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

[Kenneth]

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.

[Andreas]

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

[Kenneth]

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.