Author Topic: Cortex[TM] M3 SysTick  (Read 16610 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3237
    • View Profile
    • uTasker
Cortex[TM] M3 SysTick
« on: November 11, 2007, 01:32:46 AM »
Hi All

I have just integrated the uTasker system TICK using the in-built SysTick timer in the Cortex TM M3 core (that is what is for). Here are some more details about the work:

System TICK

The Cortex™ M3 has a timer built into the core called the system timer (SysTick). This is suitable for generating a tick for an operating system or for measuring delays. Since it is designed for generating a system TICK interrupt this is exactly what we are going to do with it. One interesting advantage of having the SysTick in the processor core (apart from the fact that it doesn’t have to be taken from a peripheral timer) is the fact that any Cortex™ M3 based processor will operate identically (apart from the actual match counter setting which will be defined by the tick period and also the system frequency) and so it is not necessary to write any more timer code to suit the next chip.
[A possible exception is when the code uses the SysTick calibration register. This register is not implemented in the Luminary Stellaris devices and so its use is avoided.]

The operation of the SysTick and various other registers belonging to the Cortex™ M3 memory range (private registers) is described in the original ARM documents rather than the chip manufacturers’ documents. This means that it is a good idea to have a collection of ARM documents and application notes – various are supplied on the Luminary Micro’s evaluation kits but all are available on the Internet as well.

I must say that the Luminary Micro documentation is really good. It is well written and proof read and presented in a quality that I haven’t seem before. Even companies like Freescale, who produce quite good documentation, could learn from Luminary. The number of errors in the Freescale data sheets is quite high – false pins and register addresses and bit names are quite frequent until the documents have been updated a few times. Also various cut-and-paste errors are common for new data sheets where it is obvious that it was correct for the older device the newer one is based on but requires some interpretation to be able to work out what it means for the new chip.

The Luminary documentation is very new and already has an incredibly good quality and accuracy. I am very impressed!
The ARM documents are certainly very detailed and probably very accurate (although it is a little more difficult to verify this) but they are all written with a style and font which gives me the feeling that I am reading open source documentation or an operating system guide from the mid-80s. My eyes tend to fall to when reading – GCC documentation tends to do the same to me. Thinking about it also the IAR documentation has a similar look. But this is going a bit off topic now. It suffices to say that I like the modern looking style plus the quality and accuracy of the Luminary documentation and it doesn’t put me to sleep, so I may well make faster progress that expected…

For a bit more detail about using the SysTick I consulted an ARM application note 179 (

The SysTick timer is quite interesting because it uses a reload value which is loaded to the counter when the timer is enabled. This counter counts down until it reaches zero and can generate the SysTick interrupt, when enabled. When single stepping in the debugger the counter value can be seen to also be stopped when the processor is stopped, thus it is not free running from master clock but only counts when the processor is actually also running.

If you monitor the count value from a break point at the start of a block of code and then compare the value at a break point at the end of the block of code, you can quite easily work out the execution time – as long as it is less that one tick interval it is equal to the difference in the count value and has a resolution of one clock cycle!

Comments welcome. More to follow...