Daisy-Chaining Timers

Why not implement the second 32 bit counter in a RAM variable.  On each timer overflow of Timer1 just increment your RAM 32 bit counter.

If you need something to happen on a particular timer value, just do a compare with the RAM value to see if you are close; ie the RAM value is the same as the desired value, then setup a timer to trigger on the low 32 bit value.

Otherwise could you give us an idea of what your application is.

Hello All,

Since Wade has brought up the point of a RAM variable as the upper 32-bit counter, what is the duration for which the 64-bit timer need to run for a periodic update? Having the application information would be useful.

On a side note the TM4C123 has a dedicated 64-bit timer.

Regards

Amit

Kindly accept this as, "Bravo #2" for Wade's, "Ram variable increment" upon 32 bit timer roll-over.

Reading between his lines - Amit may be suggesting some caution and/or limitation in this implementation - especially if the 32 bit timer is being clocked @ "full bore."  (i.e. no pre-scale in play - full system clock {although I may be confusing this vendor's timer clocking variability w/that of other ARM vendors})

I'll hazard the guess (MCU manual deprived - this time - this place) that the 32 bit timer is unlikely to "skip a beat (or several)" even if roll-over detection & interrupt service duration exceeds the timer clock's period.  My sense is that the timer will still be clocked (i.e. that the 32 bit timer increment/decrement) will still occur - even if the code is "engrossed" in interrupt service.  (i.e. incrementing the Ram variable) (or variables - read on...)

While Amit highlights the 64 bit timer's availability - these are not in abundance.  (and cease @ that 64 bit level)

I note/highlight the fact that new poster Wade's method may easily extend to (32 bits * n) with only a slight increase in execution time.  (i.e. we now check for roll-over of the rolled-over variable(s)!)  This reporter/others often employed this means to "extend" our puny 16 bit timer/counters - in days past - when (enfeebled) MCU dinosaurs ruled the earth...

Wade - you are making valued contributions already - welcome aboard this "nanosecond pulse generating/24bit ADC challenged" fruited plain...  (may be a bit "inside" yet Amit/Roberto - intense others - surely sigh/comprehend...)

note: "extra credit" for those catching (and/or appreciating) "roll-over of the rolled-over variables."  [tech may not have to be always, "cut & dry" i.e. "stilted, by the book" unimaginative or as Homer would proclaim, "BORING!"]

Amit Ashara said:

On a side note the TM4C123 has a dedicated 64-bit timer.

 time to time I see 123 and 129 family are not so close as we expected, many peripheral are different and some get more feature other left like this. On other way 129 series has EPI is not present on 123 gaining internal/external access from/to high speed FPGA dedicated hardware solution.

 Maybe the more speed got trouble to ahead of syncing two timer or some unknown to us decision to cut out feature. The remarkable are different pin function like input out of SSI from same port.

Roberto Romano said:

The remarkable are different pin function like input out of SSI from same port.

I'd bet you (100 USD) that the SSI pin switch was less "remarkable" and more a simple, "rush/screw-up!"  That trap should surpass the - underwhelming/proper emphasis, "PF0/PD7 default as NMI" should receive - in causing (mostly unnecessary) user pain/suffering...  (only thing slowing that train is the relative scarcity of 129!)

Surely you're right (again) and I'd suggest a clear, detailed summary chart - which in one place - lists each/every MCU difference - likely to derail (we) hapless users...

Hi All,

App requirement :
I need free running timer with resolution of 100 ns, that can serve as real time clock.
Timeout can be set between 1ms and several days.
CPU is in sleep mode (this is requirement why I need hardware cascading) and wakes up when timer expires;
In this case CPU will wake up 2 times per timeout ( one for 32 HI part time and one for 32bit lo part)

Best regards,

Miljenko

cb1_mobile said:

Surely you're right (again) and I'd suggest a clear, detailed summary chart - which in one place - lists each/every MCU difference - likely to derail (we) hapless users...

 Partially done something during your post activity...

 129 series is still young and not GA available this moment, this is more scaring me than issue I can learn from other and we can fix together than see under beginner C issues or timing not grasped behaviour.

 On my point of view I am satisfied of what I drill out from new chip from now and also if hardware issue exist I know now how to bypass them. Many thing can be improved but TI stay away from NRND or punitive expedition can be organized by us to commercial people!!!

Miljenko Vresk said:

Timeout can be set between 1ms and several days.

 Hi Miljenko, so I suppose your CPU can painless get out of sleeping task, can also get out with some quiet awake and simply set ram variable, evaluate new compare then decide to wake up something other also on shortest delay.....

 Why not using the 123 family?

Miljenko Vresk said:

In this case CPU will wake up 2 times per timeout ( one for 32 HI part time and one for 32bit lo part)

 Uhm.. feeding timer with 120MHz time out after 2^32 tick.. just to see where it is 1mS is 120.000 clock cycles so timer compare can be setup again taking all time we desire/need.

 Timer timeout on 32bit get after 2^32 clock tick are elapsed, this time is multiple of 8.33nS tick, multiplied by 4billion of 2^32 interrupt cpu after 35.791394133 second, stay awake for some couple of clock tick then get back to sleep...

Miljenko Vresk said:

CPU is in sleep mode (this is requirement why I need hardware cascading)

I'm unsure if you've fully/properly, "made your case" for HW only Timer cascading.  Have you considered the duty cycle (extremely low) to "wake from sleep - increment Wade's roll-over variable?"   I'd like to know how/why you deal w/this.

Further - while in sleep mode - does the MCU Timer spec continue - in all accuracy/usage aspects?  (I haven't reviewed that spec in awhile)  And - you are likely operating from a battery - may be exposed to varying temperature - won't change in voltage/temperature impact your xtal or oscillator's frequency?  Again - I'm uncertain - suggesting that you confirm the correctness of your attempt.

As vendor's Amit advised - appears that a 64 bit timer is in residence - again I'd check that it behaves to spec while in "power saving" modes.

You've not stated any accuracy requirements - in general the ideas presented here should work - but as always - devil lurks in such fine (yet too often missed) detail...

Roberto Romano said:

 Why not using the 123 family?

Does not meet the minimum hardware requirements :(

In new design I want to replace stm32f407 with tm4c1294ncpdt

Miljenko Vresk said:

Does not meet the minimum hardware requirements :(

In new design I want to replace stm32f407 with tm4c1294ncpdt

 Another taste of asking again the same:

 Why TM4C1294ncpdt need to cascade two 32bit timer when you need a simple 1mS shortest delay? Still you can plan where is on next compare low part of timer and no need for capture high part exist... Also if overflow exist you can simply take care from a simple software shared variable or better use a semaphore to access resource and delaying update of overflow ram timer... I don't see a so time constraint than just sync up the updating task and reading task, if event is hardware related to have resolution of 100nS sw jitter free no issue at all are present on pulse.. I am right or something are you still hiding to us is in place in your mind view only?

Miljenko Vresk said:

In new design I want to replace stm32f407 with tm4c1294ncpdt

Let the influx of delayed/withheld specs continue!

Too much (endless) I want, I need...  never, "Why such is desired/required!"

Migration to far slower, less capable part seems hard to justify...

I forgot to say that I have a limited power supply.
CPU will be in deep sleep while wait for interrupt.
If timeout occurs every 2 days two interrupt will spend less energy than if interrupts is occurs every ms.
Main goal is to get the behavior as described in http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430 paragraph Clock Tick Suppression

Miljenko Vresk said:

forgot to say that I have a limited power supply.
CPU will be in deep sleep while wait for interrupt.
If timeout occurs every 2 days two interrupt will spend less energy than if interrupts is occurs every ms.
Main goal is to get the behavior as described in http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430 paragraph Clock Tick Suppression

 I forgot...

 We forgot...

 We too many time forgot stop try help helpless man like this one say useless answer to who try to understand what is trying to do and we definitively see they don't have the also minimal idea of what they where doing....

 On TIVA is not possible, TIVA is not Ultra Low Power, from MSP I own an unsold programmer still active from battery from beginning of year 2007, battery are lasted some years ago but is still running and if you press a button respond to interrupt and run program from sleep it exit every second two time to do a single pulse to one red led then to a green led. Due to this Led thick flash all the hardware consume 1uA, battery never lasted... I leave it working till battery do some sign of leakage...

 If you remove led from circuit it consume a small fraction of a uA, so few cycles to reset interrupt and reprogram timer doesn't change power drain...

 When someone come there messing up.. this is different.

Hello Miljenko,

Have you checked the Hibernate Mode for TM4C devices which works of a 32K Clock. The resolution will not be 100ns but if the prime criteria is low current consumption, then I would suggest the same if a MSP solution does not work for your application

Also to make a point here on deep sleep, please note that the clock has to be minimum of 10MHz for the 100ns requirement you have previously mentioned. You would not get much advantage over Sleep mode if the PIOSC is still the deep sleep clock.

Regards

Amit

Amit Ashara said:

Also to make a point here on deep sleep, please note that the clock has to be minimum of 10MHz for the 100ns requirement you have previously mentioned. You would not get much advantage over Sleep mode if the PIOSC is still the deep sleep clock.

 Amit, the technique of cycle stealing on MSP430 over ticking TIRTOS contribute leaving kernel in a sleeping state to save battery...

 When is powered from battery we can try all is possible to harvest low DCO usage. If it is powered still from DCO or external HI speed oscillator power drain raise so much that cycle stealing is also useless on MSP too. 

My MSP programmer is forever in low power, execute interrupt to flash a led then reenter IRQ to power down after 1 or two clock tick and preparing  flash the other led... on so many year of two IRQ a second never exhausted AAA battery from there is run.. Processor is run from 32KHz and forever sleep, all peripheral are deep sleep other when an external processor is connected and waked up from button IRQ, then DCO is run at 12MHz, all peripheral are inited again program processor it -check protect then power down peripheral, and go to DEEP sleep with led on and after few tens of second (one interrupt at second) return suddely on sleeping task.

 The MSP is not TIVA and TIVA is not MSP.

 So when 1mS delay is to be in place why a so far resolution of 100nS? Again what is still missing from telling us and probably tens of post after.. so I forgot this or that...

 Not so close to be credible too.

Miljenko Vresk said:

goal is to get the behavior as described in http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430 paragraph Clock Tick Suppression

Might you have included that note w/in first post?  (along w/your caring summary - to ease the efforts of your helpers)

Would not the simple, "Reduction in the speed of System Clock" - just prior to entering Sleep Mode - enable you to exploit the vastly more common, 32 bit Timer?  (when you awake - as/if needed - you can then, "Crank up the Clock"  - and retard it - prior to again, "sleeping.")