I2C read + interrupt doesn't happen when ulTaskNotifyTake() is used

Kernel
1

I notice that when I use ulTaskNotifyTake(), interrupt doesn’t happen, which probably is because in the logic analyzer, I don’t see the read command is issued from the readI2C()
. Is ulTaskNotifyTake() blocking the driver API?

In the debugger, I see the interrupt is enabled but the nrf_drv_twi_rx() doesn’t seem to fully get executed as I don’t see a task trigger being invoked which is why I don’t see a read request being sent in logic analyzer.

When I don’t include ulTaskNotifyTake(), I see the read goes through fine

void irqCallback( void * p_context)
{ 
    Sensor *obj = static_cast<Sensor*>(p_context);
    // store data into a buffer...
   vTaskNotifyGiveFromISR(obj->taskHandle, pdFALSE); // signal back to the test 
}

void Sensor::mainThread()
{
    writeI2C();   

    while(true)
    {   
        readI2C();

        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        processData(_buffer);
        // ...
    }
}

void Sensor::readI2C()
{
    ret_code_t err_code = nrf_drv_twi_rx(&m_twi, ADDR, _buffer, 2);
}```
2

What happens when you turn off compiler optimizations?

3

Set to optimization level of 0…to no avail. It’s just when I set a bunch of breakpoints including in the driver, I see the everything works fine but as soon as I disable the breakpoints, and run in debug mode, I don’t see any read transfer happen in logic analyzer let alone I2C callback getting invoked…

4

I see the read function doesn’t seem to get executed with ulTaskNotifyTake() hence no interrupts. When I put the breakpoint inside a read function, it seems to work fine. Do you see anything potentially wrong?

5

If nrf_drv_twi_rx doesn’t work reliably and the interrupt is (sometimes, always ?) not generated, your code waits forever for the notification, right ? Should be doable to track the driver code to see what’s going on and maybe handle a possible problem (where the expected interrupt is NOT generated) to avoid the following deadlock. Except that you have one of the obvious issues like stack overflows etc., of course.

6

actually, it’s not about interrupts not getting generated but moreso about readI2C() not getting invoked with ulTaskNotifyTake() in place. If the read function isn’t getting invoked, ofcourse there won’t be any interrupts firing.

And how is there a stack overflow?

7

That’s a question YOU have to answer :wink: Probably you already have stack checking enabled and verified that there is no problem.
However, I can’t believe that calling ulTaskNotifyTake AFTER readI2C causes that readI2C is not being called. That would be black magic :wink:
I afraid you’ve to put more effort in debugging/instrumenting your code. Good luck !