Interrupt priorities effect on time measurements

[gvuyk07]

Posted on April 24, 2016 at 06:25

Simple question

If I set some interrupts priorities to 0, should I expect time measurements (down to the microsecond) to be inaccurate? ( using SystemCoreClock and SysTick->VAL )

[Walid FTITI_O]

Posted on April 25, 2016 at 13:55

Hi Zawyer,

The SysTick interrupt is an internal Cortex exception and is handled in the system registers. By default, it has a high priority than the other interrupt programmed by user ( as mentioned in the vector table in reference manual). So, you expect Systick interruption occurs without any preemptions (which may cause timing delay) if not reconfigured by user. -hannibal-

Simple question

If I set some interrupts priorities to 0, should I expect time measurements (down to the microsecond) to be inaccurate? ( using SystemCoreClock and SysTick->VAL )

[Tesla DeLorean]

Posted on April 25, 2016 at 14:49

Well the hardware timers/clocks are going to keep ticking regardless of what your interrupts do. The values you read from these registers will be the time when you actually do that.

If your interrupts are soaking up a lot of time, and distorting the measurements, then you need to review what you are doing. Again, as indicated before, don't confuse the priority level with the preemption level. If the SysTick interrupt, 1ms not 1us, is critical, it should preempt your other interrupt code. Review chapters on NVIC, and configuration of levels, and preempty vs priority.

[Tesla DeLorean]

Posted on April 25, 2016 at 14:52

Think of changing priority as moving carriages on a train, you can change the order, but the end of one is connected to the front of the next.

Think of preemption as getting on the express train, it is a different train, with different carriages.

[mark239955_stm1]

Posted on April 26, 2016 at 05:47

If you have concerns about the accuracy of timers read during an interrupt, being affected by other competing interrupts, then you may be able to address the problem by using the original interrupt trigger source to instead trigger a DMA transaction that reads the timer value.  The DMA won't be interfered with by the other interrupts because it works in parallel to the CPU, so it's timing won't be contaminated.

Re-reading my paragraph above, it sounds complicated, but it really isn't that bad 🙂

[gvuyk07]

Posted on April 29, 2016 at 04:15

Priorities, preemption, SysTick is independent, DMA possible approach for critical timing.

Got it. Thanks guys

[Tesla DeLorean]

Posted on April 29, 2016 at 04:37

SysTick->VAL

The SysTick is 24-bit wide, often clocking at 1/8th the CPU rate, you can miss it wrapping. For critical timing I tend to prefer DWT->CYCCNT as it is 32-bit and clocks at the CPU rate. Wraps at about a minute on 72 MHz device.