NRF_ERROR_BUSY for I2C read inside an RTOS thread

[morpho]

In the task, when I do a TWI read via nrf_drv_twi_rx(), in the second iteration of the thread, the driver function returns NRF_ERROR_BUSY.

Is it that the driver takes longer than how fast the thread runs thus initiating a second read even though the previous read transfer wasn't even done?

I'm basing it off the frequencies: Tick ISR runs at 1ms, and an I2C read takes ~5 read cycles (WRITE, ACK, READ, DATA#1, DATA#2) assuming i'm reading two bytes.

Following is a snippet:

void SystemTask::mainThread()
{       
    while(true)
    {
        A.xferData();
        A.read(); 
    }
}

uint16_t A::read()
{
     m_xfer_done = false;
    ret_code_t err_code = nrf_drv_twi_rx(&m_twi, ADDR, _buffer, 2);

    APP_ERROR_CHECK(err_code);   // errors out here!

    while(!m_xfer_done);

    return _value;	         
}

[Susheel Nuguru]

Which RTOS are you running on? Are you using this on top of C++ libraries or are this directly from out SDK?

[morpho]

FreeRTOS. I have C++ wrappers around nRF APIs that are straight out of the SDK. Also I noticed I got around it by having a delay between each read call inside a task via xTaskDelay() so I suspect it has to do with timing

void SystemTask::mainThread() {

  A.xferData(temp, 1);

  while(true) { 
     value = A.read(); 
     vTaskDelay(pdMS_TO_TICKS(1000));

Update: 

With a 1000ms delay between each read, I see the program went into a bad state at some point. Below is the call stack:

[Susheel Nuguru]

That address is Hardfault inside the MBR in Softdevice. I am not sure why this occurs? Can you attach your project for me to test in on my desk?

[morpho]

I am afraid you don't have the sensor it's reading in the system task. Attaching it anyways

SmartWatch 2.zip

[morpho]

now I see this