Getting a timestamp from systick timer

[lpcware]

Content originally posted in LPCWare by celephicus on Tue Aug 21 15:35:48 MST 2012
Greetings,

I am using the systick timer to generate the usual 10ms interrupts, and incrementing a counter on every interrupt. What I now need is timing resolution to the microseconds to catch a nasty little realtime bug.

I think that the following pseudocode will work:

disable_interrupts()
timer = systick_counter
ticks = my_tick_counter
if isSystickInterrupt Pending():
    ticks += 1
enable_interrupts()

The check for a pending interrupt catches the case where I read the systick counter just after is has hit zero and been reloaded, but before the systick ISR has incremented my tick counter.

Will this work?

[lpcware]

Content originally posted in LPCWare by ToBeFrank on Wed Aug 22 19:04:32 MST 2012

---

Quote: celephicus
Greetings,

I am using the systick timer to generate the usual 10ms interrupts, and incrementing a counter on every interrupt. What I now need is timing resolution to the microseconds to catch a nasty little realtime bug.

I think that the following pseudocode will work:

disable_interrupts()
timer = systick_counter
ticks = my_tick_counter
if isSystickInterrupt Pending():
    ticks += 1
enable_interrupts()

The check for a pending interrupt catches the case where I read the systick counter just after is has hit zero and been reloaded, but before the systick ISR has incremented my tick counter.

Will this work?

---

I'm confused what you're asking. I'm assuming the code above is for getting the tick counter from your 10ms systick, not the microsecond timing you're asking about? If so, the systick at 10ms resolution won't roll over for 497 days. Will your device really be on continuously for that long? If the answer is yes, a simpler solution is to use a uint64_t for the counter variable. It will add minimal extra time to your systick interrupt and you won't have to worry about rollover.

For the microsecond resolution, use one of the hardware timers and configure the prescale to give you 1us counts.

[lpcware]

Content originally posted in LPCWare by frame on Wed Aug 22 04:58:46 MST 2012
This might well be an priority issue.

A higher-level priority interrupt will 'displace' a lower level one, seemingly adding to his run time.
You might as well review your interrupt priority distribution.

I know of those nasty bugs, where for instance an SPI interrupt was not served in time,
generating overflows and busting a protocol under certain conditions...

[lpcware]

Content originally posted in LPCWare by celephicus on Wed Aug 22 02:33:32 MST 2012
Well I tried this today, and gave it a test over lunch by dumping out 10000 timestamps as fast as I could ask for them (about 16 per sec). The delta between adjacent timestamps was always about 63000, so no funny business from timer overflows. Of course this is not a real test, since as I have a 12MHz clock, the systick timer is reloaded with 120000 to give me the systick rate of 100Hz. So I suppose that would need to get at least that number of timestamps to get a good chance of showing an error.