GPIOTE High-accuracy interrupt latency

[erik_fw]

Hello,

Our product is configured to use 3 total GPIOTE channels –– 2 sensors configured for "high accuracy" GPIOTE events, each around 10Hz refresh rate, and 1 using "low accuracy" at 1Hz rate. In our interrupt handlers for each respective sensor, we're simply setting a (volatile) data-ready flag.

We've been finding that, sporadically, we seem to be "missing" some of these interrupts. They are more heavily correlated during periods of BLE activity (which is about once per hour), but also happens even when BLE isn't active for minutes before or after. This can be broken into two main issues:

1. Latency between sensor pin being set and seeing our data ready flag get raised. As in, when we check the GPIO level for each of these sensors to test for this, we will sometimes find that the sensor's interrupt pin is set, but our data ready flag has not been set yet, meaning that somehow we are still executing non-interrupt application code in between the sensor raising its interrupt pin and the GPIOTE IRQ handler going off. Usually, the interrupt will still go off and our data ready flag  will still be set, but only after a few more lines of application code are run. Is this expected in any known scenarios? 

2. Interrupts missed completely, as in the IRQ handler for the given sensor will never actually be called as a result of the sensor interrupt pin being raised. In these instances, the sensor won't clear its interrupt pin until we retrieve data from the sensor, but since the IRQ didn't go off, we would be going an indefinite amount of time without getting sensor data if we didn't add safeguards to detect these "missed" interrupts. This happens with both the "high accuracy" and "low accuracy" GPIOTE configurations.

I've looked through the NRF52's relevant documentation to try to address these issues but haven't been able to find anything that would explain why we would be seeing the above issues. 

[erik_fw]

Hi Vidar,

I have some test results and was able to capture this issue occurring while recording with a logic analyzer, the results are attached below.

In the top row (DIO 1), a GPIO is being set during the ISR that sets our data ready flag.

In the middle row (DIO 0) is the sensor's interrupt pin (active low).

The bottom row (DIO 6) follows a GPIO that is being set on the first line inside this conditional where the sensor's interrupt pin is active but data ready flag hasn't been set yet.

The latency between interrupt pin being active and ISR executing doesn't look concerning, it's around 8μs on average which seems like what we should be expecting. 

Do you see anything concerning here or does it seem like this is just a natural case of the processor completing its pipelined instructions before executing the ISR that we are hitting by coincidence some small % of the time?

Thanks again!

[Vidar Berg]

Hi,

Thanks for the logic trace. It's interesting that the IRQ is asserted but the flag ist still read as zero afterward from main the context. The timing looks as expected at least.

I think you can test the theory related to pipelined instructions by placing instruction barriers (__ISB()) and maybe __MSB for good measure. 

By the way, are you testing with or without compiler optimization, and is link-time optimization enabled? And could you verify if s_imu_data_ready is loaded from RAM in the conditional check?