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. 

[Vidar Berg]

Hi,

Is only one of the sensors that set the s_imu_data_ready flag? 

erik_fw said:

I understand that the processor will still execute its current operation when a hardware interrupt arrives asynchronously, but seeing a full conditional execute in between the logic level change and ISR execution seems bizarre to us.

Agree. CPU should stop execution and fetching of new instructions immediately after an interrupt has been triggered.  And it should only return to the main context when there are no pending interrupts left. This makes me think that either the IN event is not triggered or the s_imu_data_ready flag is cleared before it's read by the if statement.

I think a logic analyzer/scope could help us understand the problem better if that's an option in your case. If you have enough IOs available, you could use PPI and configure a GPIOTE output task to toggle the output when an IN occurs. That way you could verify the time it takes from the sensor IRQ line is pulled low to the GPIOTE IN event and possibly detect missed IRQs.    

  

[erik_fw]

Yes, only one sensor is setting that particular flag, the other sensors use their own flags. The flag is only cleared when we, in a different section of code, check the flag and retrieve data from the sensor if it is set. 

Great point about using a logic analyzer to measure the latency, we have a logic analyzer and haven't tried that yet. I'll try that out and come back with more information!

[Vidar Berg]

erik_fw said:

Yes, only one sensor is setting that particular flag, the other sensors use their own flags. The flag is only cleared when we, in a different section of code, check the flag and retrieve data from the sensor if it is set. 

 Thanks for confirming. But if readout of the sensor is delayed, is it then possible that imu_data_ready() might be called just before the flag is cleared? For debugging, would it make sense to add a check for s_imu_data_ready to see if it's indeed '0' when you enter imu_data_ready()?

[erik_fw]

For all 3 sensors, the interrupt pin stays active until we retrieve the frame of data from the sensor. So we should never be seeing two interrupt triggers occur before data is retrieved.

[Vidar Berg]

Ok, thanks. I think I have a better understanding of your code now. Hope a logic trace will give us some more clues.