https://devzone.nordicsemi.com/f/nordic-q-a/33403/interrupt-latency-really-higher-that-specified-in-the-arm-specificationGood evening, I determined the numbers of clocks necessery to fire up an interrupt from an GPIOTE event. My debugger reports 1373 clocks ticks to go into and go back from the interrupt. In the Cortex-M4F technical documentation, I found that to enteren-USTelligent Community 13Sat, 14 Apr 2018 19:31:45 GMThttps://devzone.nordicsemi.com/thread/128337?ContentTypeID=1Sat, 14 Apr 2018 19:31:45 GMT137ad170-7792-4731-bb38-c0d22fbe4515:f33aeab4-f56e-4301-9185-6276d5082d2fSylvain<p>I implemented by myself the IRQ Handler and now I have the same interrupt latency, than it informed in the Arm Cortex-M4F technical specs.<br /><br />Thank you, for your answer.</p> <p></p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/128333?ContentTypeID=1Sat, 14 Apr 2018 16:52:41 GMT137ad170-7792-4731-bb38-c0d22fbe4515:ae26ff10-6762-42bd-aad4-7cd37ad42433Turbo J<p>The in_pin_handler() gets called from inside a handler function, after quite some code is executed in nrf_drv_gpiote.c source file. If you wanted to measure latency, you&#39;d have to implement the GPIOTE_IRQHandler() yourself. That is the name of the <em>actual</em> handler function, and its implementation looks quite long to me.</p><div style="clear:both;"></div>