I2C Read transfer doesn't happen with ulTaskNotifyTake

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Wed, 14 Jul 2021 04:09:56 GMT

let's follow up on -> devzone.nordicsemi.com/.../twi-driver-remains-busy-right-after-the-nrf_drv_twi_tx-even-though-tx-transfer-is-completed

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Tue, 13 Jul 2021 04:42:04 GMT

I also added a simple GPIO write function call after the read function and the gpio write was successful but the read function still doesn't seem to fully execute i.e don't see read bytes being sent in the logic analyzer. Can you confirm if the nrf_drv_twi_rx() isn't causing any trouble? (i doubt though but still)

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Mon, 12 Jul 2021 01:35:51 GMT

processData() is mainly just using the raw sensor data to generate an appropriate output value. If you bail out from the function itself, don't you think you'd be most likely to lose the data as opposed to only processing once you know there's something to process?

Also when I put the breakpoints inside the nrf_drv_twi_rx(), and run in the debug mode, I see things running in an expected manner, and if I don't put breakpoints, and I have xTaskNotifyTake(), initiateI2cRead() doesn't get fully executed hence no interrupt generation.

And you're right about using portYIELD_FROM_ISR() inside the ISR but that's not the solution.

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

Susheel Nuguru — Fri, 09 Jul 2021 11:03:36 GMT

[quote user="morpho"]If I'm understanding correctly, above is the flow. If that's true, don't you think you're missing out the processing of certain reads in case data wasn't read by the time processData() was invoked? [/quote]

I can't see the implementation of processData(). Normally if there is no data available, then the implementation of processData should be able to detect that there is no new data and bails out early.

If you are very confident that you do not need such early bailout mechanism and also you are sure that this function's global data is being protected using some critical sections, then I would not look into this direction. Lets try to focus more on the visible code you provided.

            if (p_event->xfer_desc.type == NRF_DRV_TWI_XFER_RX)
            {
	            vTaskNotifyGiveFromISR(obj->taskHandle, pdFALSE);
	            
            }

try notification from the ISR this way.

    BaseType_t yield_req = pdFALSE;

            case NRF_DRV_TWI_EVT_DONE:
            if (p_event->xfer_desc.type == NRF_DRV_TWI_XFER_RX)
            {
                vTaskNotifyGiveFromISR(obj->taskHandle, &yield_req);

                /* Switch the task if required. */
                portYIELD_FROM_ISR(yield_req);
            }

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Thu, 08 Jul 2021 04:38:50 GMT

Thanks for the response.
sorry, I'm still not fully convinced as to why would processData() be still after ulTaskNotifyTake. Isn't the main idea behind ulTaskNotifyTake to block the current task till data is ready to be processed? Perhaps why even go inside processData() if there's nothing to process, plus what are you blocking the test after processData() via ulTaskNotifyTake for?

if this is the flow, and assuming processData() doesn't do anything if there's no data, I assume the following flow:

- interrupt is enabled but data hasn't been read yet

- processData() is invoked but nothing to process

- block the task till the I2C data is fully read. Unblock it once the data is read but it's not processed

- repeat the loop --> go on to read the next i2c data

If I'm understanding correctly, above is the flow. If that's true, don't you think you're missing out the processing of certain reads in case data wasn't read by the time processData() was invoked?

while(true)
{
initiateI2cRead();

processData();

uint32_t taskNotify = ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

}

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

Susheel Nuguru — Tue, 06 Jul 2021 07:31:40 GMT

Sorry for late response morpho.

Normally processData should do nothing if there is no data (it is normally waste of cpu time the first call) but it avoids one race condition when your application state machine depends on process data to complete for preparing for the next transaction.

I would still recommend you to have process data first and call ulTaskNotifyTake . It would only make difference the first call. Then it would be a loop like how you have it now (minus the race condition possibility)

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Fri, 02 Jul 2021 17:20:09 GMT

Any idea Susheel?

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Wed, 30 Jun 2021 14:17:07 GMT

Wouldn't it make more sense to process the data after it's been signalled from the interrupt rather than spinwaiting till the data is ready to be processed first? That was the point I decided to use ulTaskNotifyTake so the task is blocked till the data is received, and processed only after

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

Susheel Nuguru — Wed, 30 Jun 2021 10:48:48 GMT

seems like your app's state machine is stuck at ulTaskNotifyTake. Probably best to have ulTaskNotifyTake after processData() to kick off the send/receive properly and then wait for the events?

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

morpho — Mon, 28 Jun 2021 16:07:19 GMT

sorry, the init function isnt shown. As mentioned, it works without the ulTaskNotifyTake, which should’ve hinted at init function is indeed invoked

RE: I2C Read transfer doesn't happen with ulTaskNotifyTake

Andre — Mon, 28 Jun 2021 08:16:55 GMT

You need to initialise the twi peripheral using nrf_drv_twi_init() before you can call nrf_drv_twi_rx()