NRF_TWIM_IS_BUSY is taking up to 12ms to return

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

paul — Thu, 02 May 2019 22:17:06 GMT

Thanks Einar,

yeah I am aware of that issue, been bitten before. I believed I needed to copy the data out so needed something to put it in. What was worse it turns out was that I was never actually looking at the value and so never freeing it. As the unfreed buffer count mounted the timing stretched out. This is one of the easy mistakes to do when doing event driven since things happen in many different places.

Your suggestion to trace it was what finally cracked the problem.

Many thanks

Paul

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

Einar Thorsrud — Thu, 02 May 2019 10:39:39 GMT

Hi Paul,

I was wondering if the slave did clock stretching, but it does not seem like this delay is directly related to TWI or the driver. Rather, you say that you do some work in the event handler (callback), and that could definitely explain this, since the driver waits with setting the internal busy flag to false until after executing the callback.

It is generally is bad practice to spend much time in the event handlers in the SDK. If you need to much work at this point it is typically better to defer the execution of the work to the main/thread context, for instance using an app scheduler or a simple volatile synchronization variable. This way it will not run in interrupt priority, and the event handler (which is essentially part of the TWI interrupt handling) is made as short as possible.

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

paul — Wed, 01 May 2019 04:29:39 GMT

Hi Einar,

we don't own a logic analyser however we have done the following testing:

1) replicated the problem with an LP5018 LED controller on the same bus and using the same code. It also stretches out to around 13ms

2) We watched the transaction on the cro with the result:

a) 2 bytes written

b) 12 bytes returned

Total time activity on the bus is about 400us. It then takes the rest of the about 13ms in the handler or the wait for busy to say we are not busy. I have attached a couple of photos.

<code>

while(1) {

GPIO_debug_on(true);
byte_read_multi_twi( 0x28, 3, buf, 12);
GPIO_debug_on(false);
nrf_delay_ms(1);
}

</code>

the following picture shows the full transaction. The bottom trace is the GPIO pin going high before the call and going low afterwards. The dip is the 1ms delay put in just to make it easier to see where the cycle starts.

The top trace shows the data line on the i2c bus. As you can see it starts soon after the timing period and then stops and there is a long time of no activity. The actual transation - ie data on the bus - takes 400us which was our rule of thumb expectation it would take.

This trace shows the activity on the i2c bus. The bottom trace is the clock at 400khz. The top is the data line. This looks like an address, then register, then 12 bytes coming back.

This trace shows the stop condition at the end of the transfer with both the clock and data line going high.

We are using nrf_malloc in the twim event handler to copy out the data returned. This is taking the 13ms. Removing the malloc produces this with a 100us delay between reads.

I guess the question is whether nrf_malloc should be taking up to 13ms to run? At this stage, I have removed the offending code and my sampling cycle has gone down to my target timing.

Cheers Paul

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

Einar Thorsrud — Tue, 30 Apr 2019 09:21:22 GMT

I see. But I do not understand what is causing this, so it would be interesting to see what is actually happening on the TWI lines. Do you have a logic analyzer trace showing this? It would be even better if you could include the debug GPIO pin you toggle before and after nrfx_twim_is_busy() in the same trace.

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

paul — Tue, 30 Apr 2019 04:53:42 GMT

hi Einar,

as far as I can see, the chip itself does the following:

1) reads the value

2) sets a flag on the chip to say it is done

3) I then do the read of the results

4) this read steadily gets longer.

for what its worth, the chip is an ST vl53l0x time of flight or distance measurerer.

Cheers Paul

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

paul — Mon, 29 Apr 2019 22:23:07 GMT

Hi Einar,

the following code takes 12ms:

while (1) {
GPIO_debug_on(true);
if (!nrfx_twim_is_busy(&m_twim))
break;
GPIO_debug_on(false);

}

All the GPIO_debug_on does is toggle a gpio pin attached to a cathode ray oscilloscope. The switching of the gpio pin allows measurement of the time taken.

Cheers Paul

RE: NRF_TWIM_IS_BUSY is taking up to 12ms to return

Einar Thorsrud — Mon, 29 Apr 2019 12:13:59 GMT

Hi,

I am not able to see from the question where the unexpected delay is. Can you clarify? Is it some function that returns NRF_TWIM_IS_BUSY, but waits for too long before returning it? Which function? Or something else?