SysTick less accurate than expected

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SysTick less accurate than expected

1,330 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mfc on Mon Jan 30 03:02:27 MST 2012
I was hoping to use SysTick as a precise real-time clock by setting the SysTick count to interrupt every 100 microseconds and then simply counting (every 10,000 counts bumps a seconds counter, [I]etc[/I].).

On running this overnight, I find that there were 0.3% more interrupts than expected (3000 parts per million, whereas the external 12MHz crystal from which the clock is driven should be within 30 ppm).   This equates to a gain of about 270 seconds (4.5 minutes) per day, which is too large for my application.

Anyone have any ideas what might be causing this?  I've checked the SysTick CALIB register and it has the expected value (0x000F423F) for the 1768 chip that I'm using.

Many thanks -- Mike
0 Kudos
6 Replies

1,034 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mfc on Sun Feb 05 03:52:03 MST 2012
Mystery solved.  The SysTick_Config inline routine (in core_cm3.h) has the undocumented side-effect of setting the SysTick interrupt priority to lowest (by default it is at highest priority).  Since my interrupt handlers for accelerometer and gyro were at a medium priority and could run for more than 100us this caused occasional lost SysTick events (overrun).

My first measurement (where the clock appeared to run fast) must have been in error, as all subsequent ones showed the clock apparently running slow by 1.2% or so.  The crystal oscillator was stable with 13ppm.

Many thanks for the suggestions, etc.

Mike
0 Kudos

1,034 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mfc on Mon Jan 30 07:24:06 MST 2012

Quote: stalisman
It is interesting that you are running your interrupts 100 times faster than suggested and that your errors are 100 times greater.

Given that the individual errors for each 100micro second timer, each with an associated 30ppm inacuracy, will accunulate over night is not something like this to be expected?



Hmm, that's an interesting observation.  But I'm not sure how it 'adds up'?

I'm asking for an interrupt every 9600 clock ticks.  The hardware should be doing exactly that.  So there should be 10,000 interrupts per second.  If I asked for an interrupt every 960000 ticks (100 per second) why would that be more accurate - they are the same ticks being counted?  I just count them 9600 at a time rather than 960000 at a time?

[Offline suggestions are that I have a 'bad' crystal ... will try and borrow a high-spec frequency meter to measure directly.]
0 Kudos

1,034 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by stalisman on Mon Jan 30 04:25:50 MST 2012
It is interesting that you are running your interrupts 100 times faster than suggested and that your errors are 100 times greater.

Given that the individual errors for each 100micro second timer, each with an associated 30ppm inacuracy, will accunulate over night is not something like this to be expected?
0 Kudos

1,034 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mfc on Mon Jan 30 03:58:37 MST 2012

Quote: Zero
User manual:
#1 If you change your interrupt to 10 ms you should get a better result :)

#2 If you change your calibration value you should get a better result :):)



Thanks, but:

#1 I am using a count of 9600 (-1 into the RELOAD register) for a 100 us interrupt [my clock speed is 96 MHz].  10 ms is too slow for my application (real-time control).

#2 The CALIB value is 'hard-coded' in the hardware, and confirms that there is no skew in the device -- so the timing should be as good as the crystal from which the system clock is derived?

Mike
0 Kudos

1,034 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Mon Jan 30 03:51:55 MST 2012

Quote:
...it has the expected value (0x000F423F) for the 1768 chip that I'm using...

User manual:

Quote:
23.5.4 System Timer Calibration value register (STCALIB - 0xE000 E01C). The STCALIB register contains a value that is initialized by the Boot Code to a factory programmed value that is appropriate for generating an interrupt every [COLOR=Red]10 milliseconds[/COLOR] if the System Tick Timer is clocked at a frequency of [COLOR=Red]100 MHz[/COLOR]. This is the intended use of the System Tick Timer by ARM. It can be used to generate interrupts at other frequencies by selecting the correct reload value.

#1 If you change your interrupt to 10 ms you should get a better result :)

#2 If you change your calibration value you should get a better result :):)
0 Kudos

1,034 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by gbm on Mon Jan 30 03:20:49 MST 2012
Systick timer is as accurate as your frequency source. Check your oscillator.
0 Kudos