• State Answer Suggested
  • Locked Locked
  • Replies 21 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1613 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Running time of M3

Soren Bendtsen
Prodigy 60 points

Hi,

I am using a LM3S9D92 for a project and I need to get the "running time" of how long ago the system was powered on. The more accurate the better. The running time can be hours and days and should have a resolution of milliseconds.

I looked at the SysTickValueGet() but it is only a 24 bit clockcount and will overflow/zero out quickly at 50 MHz. 

I tried registering an interrupt using the  SysTickPeriodSet() + SysTickIntEnable() + SysTickEnable() and incrementing a variable for each interrupt call, but it seems pretty inaccurate.

I think the best solution is using the SysTickValueGet() method, but I need to know how many times it has reloaded to be able to calculate the running time accurately.

Any suggestions?

  • 0
    Guru 26105 points

    Hi,

    I tried registering an interrupt using the  SysTickPeriodSet() + SysTickIntEnable() + SysTickEnable() and incrementing a variable for each interrupt call, but it seems pretty inaccurate.

    Why do you think it is inaccurate? On a day long and an interrupt at 10 ms then the inaccuracy will be 10 ms in 87000 seconds, which is under ppm. Need better than that? Seems to be the accuracy of an wrist quartz clock - this means 1 second in three months.

    The problem will be how to save the data before power off, at power on there no problems.

    Petrei

  • 0 in reply to Petrei
    Prodigy 60 points

    Thanks,

    It sounds like I need to test that solution a bit more. From what I could tell, it was drifting out of sync quite badly, but it could be related to other parts of the software.

  • 0 in reply to Petrei
    Guru 117855 points

    Few further considerations:

    a) Believe that 100mS interrupt rate will prove less disruptive to your overall program (especially if/when your program extends beyond, "incrementing a single variable" {i.e. data logging})  The burden of your, "storage mechanism" must be calculated as it likely will intrude upon other, priority code execution.

    b) Power on may indeed cause a problem.  SysCtlClockSet() "eats MCU cycles" and must be called prior to your System Clock reaching 50MHz.  Will not this be a source of error?  (you may be able to resolve - but it is not, "problem-free."

    c) As Petrei states - your method of "storing" the time-stamp data must be carefully considered & (likely) well tested...

  • 0
    Guru 27665 points

    A couple of thoughts

    Do you need 10ms precision or 10mS accuracy? Precision should be straightforward.  Accuracy will be considerable harder, you are approaching or exceeding the typical stability and accurracy of micro frequency sources unless you start going to more exotic sources like oven controlled oscillators

    I'm not familiar with this specific part but I have noticed a plethora of timers on a number of these parts, some with 64 bit modes.  These can be set up as 32 bit timers with 16 bit prescaler.  Set the prescaler to give you a 1 ms tick on the 32 bit timer and you have a no overhead timer with the precision and implied range you specified.  Range easily extended to ridiculous levels even w/o an interrupt.

    Also if you have a spare timer resouce that can be configured as a counter you can hook up a standard osillator at a watch frequency (32.767kHz) and use that.

    Robert

  • 0 in reply to cb1_mobile
    Prodigy 60 points

    I just tested the system, and it is indeed drifting. From the short test i did here, it drifted 250 milliseconds over an hour.

    I realize the clock in my workstation is not the best in the world, but it is for sure better than that.

    The Stellaris is doing other things, such as ADC scanning and USB communication; I suspect this can affect the interrupt accuracy (true?).

    The code to follow time is basically the interrupt example from the Stellaris samples: C:\StellarisWare\examples\peripherals\systick\interrupt.c with an a sys tick period of 1 ms (ROM_SysTickPeriodSet(ROM_SysCtlClockGet() / 1000)).

    I agree the drift could be reduced by making the period longer, but it will not solve the problem.

    The clocks cycles spent during initialization is not that important, the problem is the drift over time.

  • 0
    Guru 117855 points

    I don't believe the wider Timers will comfort in this instance.  Indeed they'll extend the potential count range - but Systick's 24 bits should realize ~335mS at full load - so adding bits will insure that mS resolution will be sacrificed/compromised.

    As for your report of, "inaccuracy" - might this spring from a too low priority setting for your Systick?  This possibility - along w/my suggestion of adopting a 100mS "interrupt period" - seems a reasonable compromise for your program requirements & time/data logging.

    Still - unstated is the method & efficiency of, "incrementing your count & storing it into some non-volatile device."

  • 0 in reply to Soren Bendtsen
    Guru 27665 points

    That's 70ppm.

    That may be the stability of your oscillator.  Not a great oscillator but not unprecedentally bad either.

    Robert

  • 0 in reply to Robert Adsett
    Prodigy 60 points

    Robert: Accuarcy of 1 milli-seconds is fine.

    I am not storing the time anywhere. When the device is powercycled, it will be starting from 0 again, so it is not "total running time" of the device I am after.

    Do you have any more information/hints/examples regarding the first solution you are proposing?

    It will be difficult to change the hardware at this point, but the added osillator could to the trick as well.

    Thank you!

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:

    Still - unstated is the method & efficiency of, "incrementing your count & storing it into some non-volatile device."

     
    He's just couting time since power on, no need for non-volatile stores.
     
    Robert
  • 0 in reply to Soren Bendtsen
    Guru 117855 points

    Soren Bendtsen said:

    The Stellaris is doing other things, such as ADC scanning and USB communication; I suspect this can affect the interrupt accuracy (true?).

    Yes - that's true.  You may raise the SysTick Interrupt priority to the highest (00) or you may temporarily eliminate those other functions which employ interrupts and which may add error...

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert Adsett said:
    He's just couting time since power on, no need for non-volatile stores.

     
    Should that be the case - what is the trigger event to "halt" the accumulation of run time?  Devil is (once again) in the detail - and no detail has been provided.
  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:

    He's just couting time since power on, no need for non-volatile stores.

     
    Should that be the case - what is the trigger event to "halt" the accumulation of run time?  Devil is (once again) in the detail - and no detail has been provided.

    [/quote]

    Power off.

    The timers and any extra needed registers must be re-inited on power on in any case and accumulation stops pretty naturally when the micro loses power.

     

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Are you not assuming that some person is physically present - at all times - and notes/logs the appropriate content just prior to, "shut down?"   Is that good - or normal - or proper - ever?

    And - what happens should an unwanted/unexpected power failure occur? 

  • 0 in reply to Soren Bendtsen
    Guru 27665 points

    You'll have to check the specific documentation for your chip but it's under general purpose timers in mine.

    If you do have a timer capable of 32bit with 16 bit prescaler than with a 50MHz clock in general outline you do this

    • Configure timer to 16bit prescaler with 32bit counter in free running mode (resets on overflow)
    • Set the prescaler to divide by 50000
    • enable timer

    To read the timestamp. Note:  This will maintain even an extended period clock as long as you read at least once per 2^31 ms. Note read timers as unsigned always.

    • Read the 32 bit timer (divide by 10 if you need 10ms count rather than 1mS)
    • if current reading is less than previous reading increment high order count (only needed if you want a range longer than (2^32)/1000 seconds)
    • Store current reading as previous reading (only needed if you want a range longer than (2^32)/1000 seconds)

    A note on accuracy.  To maintain 10mS accuracy over a day requires an osillator with 100ppb accuracy and stability.  To maintain 10mS accuracy over a month requires better than 4ppb accuracy and stability.  The above will give you 1mS precision but not accuracy unless you pay really close attention to the oscillator.

    Robert

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:

    Are you not assuming that some person is physically present - at all times - and notes/logs the appropriate content just prior to, "shut down?"  

    No

    cb1_mobile said:

    And - what happens should an unwanted/unexpected power failure occur? 

    The timer resets.

    I have done a number of systems like this.  Time is only maintained as from "when power was last applied".  If there are timed event logs (not a given) then they record the event as ocurring as some period of time after power was applied an event happened.

    And if events are recorded it's not a given they will be preserved across power cycles.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert Adsett said:

    And - what happens should an unwanted/unexpected power failure occur? 

    The timer resets.

    Not if power remains off!   The desired run-time is then forever lost...

    We've chosen vastly different, "use cases" to justify our positions. 

  • 0 in reply to cb1_mobile
    Guru 27665 points

    If the power is off the time running  since power on is sort of naturally zero ;)

    I suspect I've seen more cases of this being useful than you have.  This behaviour is strongly implied in the original spec (and verified later) but worth the question.

    One thing I have glossed over is that this, as outlined, is really time since last reset rahter than time since last power on.  Depending on the actual requirements this could be ignored or a check could be made on startup and avoid re-init of the clock if not a power-on reset.

    The part of this that would really concern me though is the implied accuracy requirement in the spec.  I did a quick check of crystals on Digikey and they range from 9ppm to 250ppm so if the implied accuracy is actually required it's going to require some hardware work.

    Robert

  • 0 in reply to Robert Adsett
    Prodigy 60 points

    Thanks for all the information guys!

    Maybe I can clarify a bit. For this project I only need the running time since the device was powered on or rest.

    It is basically a data logger, with a USB interface. Since the measured data will not be transmitted on the USB interface when measured, it needs to be timestamped of when it was measured. This is where the running time is used.

    To be able to translate the relative time (milliseconds since power on/reset) the USB host reads the relative time when it is connected (i.e at 400ms) and stores it in memory with the absolute time from its own clock (i.e 2014-01-09 14:29:32.998).
    In this case the device would have been powered on at 2014-01-09 14:29:32.498. 

    When measurements are recieved, it is then able to translate the relative time in the measurement to an absolute time by adding the relative time to the calculated power on time. 

    If the USB device is reset or power cyclced, the USB connection to the host would be lost, and the above would be repeated.

  • 0 in reply to Soren Bendtsen
    Guru 117855 points

    @ Soren,

    Thanks this further detail. 

    Returning to your issue regarding enhancements/safeguards to the accuracy of Systick - I believe these earlier comments still warrant consideration/implementation:

    a) As Robert has suggested - your SysTick Timer results are w/in "normal/customary."  You may improve SysTick accuracy via trial/replacement -> measurement of a series of System Clock xtals and/or fine tweak of these xtal's caps.  Temperature & MCU power should be held as constant as possible during these measurements.  Measuring System Clock frequency is best done via the use of a Timer configured as PWM & then output to the timer pin.  (attachment of less than a "stellar" scope probe to the MCU oscillator will likely degrade measurement accuracy)

    b) You asked about other interrupts impacting your SysTick.  Indeed - should those other interrupts be of equal or higher priority - and require more than a few uS to fully/properly service - your SysTick's measurement will be degraded.  You can eliminate this effect via: a) disabling all other interrupts during your SysTick's measurements, b) raising the priority of SysTick, c) insuring that all interrupts are serviced quickly. 

    As often w/in engineering/programming - efficiency in transferring data from your MCU to external, non-volatile storage may prove a great challenge.  Our simple solution involves the selection of an MCU w/ "massive" on-chip, rapid-access SRAM - which is regularly "blasted" w/logged data & a simplified (compressed) time stamp - and only later "passed" to non-volatile storage media...

  • 0 in reply to Soren Bendtsen
    Genius 5695 points

    The only thing that has ever worked for me is an RTC -- built in or something like the Dallas clocks -- chosen for appropriate accuracy.

    You can beat this to death -- but unless the MCU has a built in RTC clock unit that can unit tweaked to maintain accurate time it's a long uphill climb.

    Cheers and good luck with this one.

  • 0 in reply to Dave Robinson
    Guru 117855 points

    Viegaetz Dr. Robinson - pleasure to log your return - this frozen tundra...

    "Dallas" clocks telegraphs your/my "shelf life..."