Well I'll be ...! Would not have thought this has such an effect! I didn't catch initially that the OG timer_time_us_64() call was not a ramfunc, either. I replaced it withOh okay, I was looking for the second interrupt function. Thanks for pointing it out.
I haven't the foggiest idea, I'm just a cat attracted to a moving laser dot![:D]( "Very Happy")
If the interrupt handler times are so variable, can you measure the min and max and just list it out, rather than having us squint at the pix?
Code:
uint64_t __not_in_flash_func(timer_time_us)(timer_hw_t *timer) { // use lo,hi order for latched read uint32_t lo = timer->timelr; uint32_t hi = timer->timehr; return ((uint64_t) hi << 32u) | lo;}So maybe it was some kind double whammy of the read jitter plus the code being evicted from the XIP cache? And as an aside, why is the SDK code not using this mechanism in the first place?
Statistics: Posted by dognotdog — Sun Jan 11, 2026 3:41 pm