Unexpected timing value behavior when using Zephyr timing functions.https://devzone.nordicsemi.com/f/nordic-q-a/110485/unexpected-timing-value-behavior-when-using-zephyr-timing-functionsI need to measure pulse widths with microsecond accuracy using a NRF7002DK. To do that I am using Zephyr Time Functions (CONFIG_TIMING_FUNCTIONS). My SDK is v2.6.0. The pulses are routed to a GPIO interrupt that is configured GPIO_INT_LEVEL_ACTIVE toen-USTelligent Community 13Wed, 24 Apr 2024 07:59:49 GMTRE: Unexpected timing value behavior when using Zephyr timing functions.https://devzone.nordicsemi.com/thread/480352?ContentTypeID=1Wed, 24 Apr 2024 07:59:49 GMT137ad170-7792-4731-bb38-c0d22fbe4515:561fa70e-2bc0-4e8d-beaa-3ec3e1d857dcKazi Afroza Sultana<p>Hello,</p> <p>Can you try to use GPIOTE+TIMER+(D)PPI in the application like this example&nbsp;<a href="https://github.com/sigurdnev/ncs-playground/blob/master/samples/pulse_detector/src/main.c">https://github.com/sigurdnev/ncs-playground/blob/master/samples/pulse_detector/src/main.c</a>? It would be more accurate than what you have done now.&nbsp;</p><div style="clear:both;"></div>RE: Unexpected timing value behavior when using Zephyr timing functions.https://devzone.nordicsemi.com/thread/480073?ContentTypeID=1Mon, 22 Apr 2024 21:46:31 GMT137ad170-7792-4731-bb38-c0d22fbe4515:df0b8a3c-13a9-4399-bdae-077dea6c5c69Adam K.<p>I copied the callback code incorrectly as the assert and deassert time variables are declared static within the callback function.</p> <p>&nbsp; &nbsp;static timing_t assert_time;<br />&nbsp; &nbsp;static timing_t deassert_time;<br />&nbsp; &nbsp;static uint32_t k_assert_time;<br />&nbsp; &nbsp;static uint32_t k_deassert_time;<br />&nbsp; &nbsp;uint64_t total_cycles;<br />&nbsp; &nbsp;uint64_t total_cs_time_in_us;</p> <p>FYI - the erroneous timing values seem to happen as soon as the k_uptime is 64000 or greater.</p><div style="clear:both;"></div>