Why is the SysTick timer off by a few clock cycles?

How do you measure it?

JW

Thanks for the reply waclawek.jan. First I measured it using a trace tool in my IDE (TrueSTUDIO), but during my experiment I started to suspect that the deviation measured might be in the tool. Therefore, I changed to the clock cycle count register in the debug peripheral (DWT->CYCCNT), this gave me the same result.

The systick handler is as follow:

extern 'C' void SysTick_Handler(void)
{
 static uint32_t count = DWT->CYCCNT;
 uint32_t interval = DWT->CYCCNT - count;
 count = DWT->CYCCNT;
 if(interval) {
 // useless, but should prevent the compiler from optimizing interval away
 }
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

and the SysTick_Config call looks like:

// SystemCoreClock equals 168000000
if(SysTick_Config(SystemCoreClock / 1000)) {
 // Error ...
 return;
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

And finally the main loop is just a while(1) {} loop. I just rechecked the values of the experiment, and now they oscillate around

167980, but they are always below the 168000. I compiled this with the lowest optimization level (-O0), it should not matter expect that some values might be optimized out. To see the values I have a breakpoint on line 6 of the first code fragment.

Please let me know if I forgot an important detail.

Hi,

can you check the SysTick Reload value (SysTick->LOAD) and SystemCoreClock value? The reload value is derived from SystemCoreClock value: reload = ((SystemCoreClock / 1000) -1)

On my side, on STM32F429I-DISC1 discovery board with HCLK=168MHz (*), SystemCoreClock=168000000 and SysTick->LOAD=167999.

(*) Clock config: HSE=8MHz, PLL source=HSE, PLL_M=4 N=168 P=2.

Thanks for your response, its much appreciated :-).

Waclawek.Jan

TISSERAND.Bruno

SysTick->LOAD. For me it's the 167999 as well.

Jan,

I have to admit, I did not look up the actual clock count for the load- and subtract instruction, but let assume (for a worst case calculation) the instructions take 3 cycles. (I suspect that the subtract will only be on cycle and the load instruction 2, but this would only make it worst). We have 1 instruction for reading count, 1 for DWT->CYCCNT and one for subtracting. So we execute 3 instruction, times 3 cycles is smaller then 20 cycles (168000 -

167980 = 20)

I realize now that giving the code snippet was a bad idea. I encountered the problem some weeks ago. Back then, I had a program doing nothing expect for executing the SysTick irq. I measured the cycle count using an build in tool of Atollic's TrueSTUDIO, the SWV Exception Trace Log. I was surprised by the result so I tried several different configuration by changing the clock frequency and SysTick interval. Still using the SWV Exception Trace Log I measured different deviation depending on the configuration.

At first, I thought that this issue might be related to the measurement tool, so I had a discussion with the support for TrueSTUDIO. After a while we figured that, using the DWT->CYCCNT, we could show that this problem is not in the measurement tool. And so I ended on this forum.

Thanks JW for further looking into this .So basically you are saying that some cycles will be 'lost' when initiating a break for debug?

I did a quick test to verify this: I used the single point read of the DWT->CYCCNT code snippet you supplied and changed the 'useless' if-statement with a compare aganst168000.

void SysTick_Handler(void)
{
 static uint32_t count = DWT->CYCCNT;
 uint32_t current_count;
 uint32_t interval;
 current_count = DWT->CYCCNT; // single-point read
 interval = current_count - count;
 count = current_count;
 if(interval != 168000) {
 interval--;
 // useless, but should prevent the compiler from optimizing interval away
 }
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Then, to avoid using the debugger to get the infoI set a break point at line 11of this code snippet ('interval--;'). Theoretically, once the code is running, this break point should not hit right? But it did :-(. And again, the interval value is 167997 consistently.

Thanks,

Jurrien