IIC forzen

[shark]

When debugging IIC, it always crashes here. what is the problem。

nrfx_twim.c，line 441.

else
{
while (!nrf_twim_event_check(p_twim, evt_to_wait))//forzen here
{
if (nrf_twim_event_check(p_twim, NRF_TWIM_EVENT_ERROR))
{
NRFX_LOG_DEBUG("TWIM: Event: %s.", EVT_TO_STR_TWIM(NRF_TWIM_EVENT_ERROR));
nrf_twim_event_clear(p_twim, NRF_TWIM_EVENT_ERROR);
nrf_twim_task_trigger(p_twim, NRF_TWIM_TASK_RESUME);
nrf_twim_task_trigger(p_twim, NRF_TWIM_TASK_STOP);
evt_to_wait = NRF_TWIM_EVENT_STOPPED;
}
}

[Jørgen Holmefjord]

Hi,

It is hard to say exactly what is causing this, but often it is related to the pins being used by other peripherals or similar.

Can you check what is happening on the TWI bus with a logic analyzer?

Which GPIOs are you using for SCL and SDA?

Best regards,
Jørgen

[shark]

#define TWI_SDA2                			22   //touch/eeprom/oled Master SDA pin
#define TWI_SCL2                			23   //touch/eeprom/oled Master SCL pin

#define TWI_SCL1                			16   //IC/8563 Master SCL pin
#define TWI_SDA1                			17   //IC/8563 Master SDA pin

void bsp_iic1_master_init(void)
{
	ret_code_t ret;

	uint32_t *twim1_power = (uint32_t *)(NRF_TWIM0_BASE+0xFFC);

	*twim1_power = 0;	//turn off TWIM0

	*(volatile uint32_t *)twim1_power;	  //wait for register to be written (CPU runs faster than the peripherals)

	*twim1_power = 1;	//turn on TWIM0
	
	const nrf_drv_twi_config_t config =
	{
	   .scl 			   = TWI_SCL1,
	   .sda 			   = TWI_SDA1,
	   .frequency		   = NRF_TWI_FREQ_100K,
	   .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
	   .clear_bus_init	   = true,
	};

	ret = nrf_drv_twi_init(&m_twi_master1, &config, NULL, NULL);

	if (NRF_SUCCESS == ret)
	{
		nrf_drv_twi_enable(&m_twi_master1);
	}
	else
	{
		APP_ERROR_CHECK(ret);
	}
	
}

void bsp_iic2_master_init(void)
{
	ret_code_t ret;

	uint32_t *twim2_power = (uint32_t *)(NRF_TWIM1_BASE+0xFFC);

	*twim2_power = 0;	//turn off TWIM0

	*(volatile uint32_t *)twim2_power;	  //wait for register to be written (CPU runs faster than the peripherals)

	*twim2_power = 1;	//turn on TWIM0
	
	const nrf_drv_twi_config_t config =
	{
	   .scl 			   = TWI_SCL2,
	   .sda 			   = TWI_SDA2,
	   .frequency		   = NRF_TWI_FREQ_100K,
	   .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
	   .clear_bus_init	   = true,
	};

	ret = nrf_drv_twi_init(&m_twi_master2, &config, NULL, NULL);

	if (NRF_SUCCESS == ret)
	{
		nrf_drv_twi_enable(&m_twi_master2);
	}
	else
	{
		APP_ERROR_CHECK(ret);
	}
	
}

[shark]

Especially when the rate is 400K, the phenomenon of endless loops is easy to occur, and the rate of 100K is relatively small. Two or three slaves are hung on each IIC bus.

[Jørgen Holmefjord]

Are you testing this on a nRF52 DK, or on a custom board? On our DK, GPIO P0.16 and P0.17 are used for LEDs and Buttons, they may not be usable for other purposes. It sounds like not all transfers lead to this condition, how often does it happen? Is the scope screen from when the issue occurs?

[shark]

It didn't happen on the development board, it was my own board. I observed the oscilloscope when there was a problem, but the slave did not respond. I tried adding a watchdog, if the card is stuck in the loop, the system can be restarted. Even if the watchdog can restart the system, I do not want the system to restart when there is a problem with the slave. I would rather read the slave several times, rather than restarting the system frequently. It may be that the speed of the master is too fast, and too many slaves are mounted (3 slaves, some slaves can not reach the 400K rate) causing problems. However, I feel that even if there is a problem with the slave, the master should not keep looping somewhere.

[Jørgen Holmefjord]

If you are using an older SDK version, you can try to update to the latest version. Some fixes were added to TWI and TWIM drivers i nrfx 1.8.0 (used in SDK 16.0.0) to recover the bus from erroneous behaving slave devices.