Trouble with TimerValueGet64

I'm using the TM4C1294NCPDT. 

I performed a:

    UARTprintf("PPWTIMER = %d\n", *((int*)0x400FE35C));

And the result was 0, indicating that "32/64-bit wide general-purpose timer module 0 is not present"

This is surprising since the TivaWare Peripheral Driver Library has the TimerValueGet64 function call listed. I was under the impression that the TM4C1294 is the most powerful microcontroller in the Tiva series.

Does the TM4C1294, the most powerful in the Tiva series, have a 64-bit timer? If not, is there a workaround?

Vito Casa said:

Does the TM4C1294, the most powerful in the Tiva series, have a 64-bit timer?

    (political statement removed...)

Is it not likely that:

• your MCU indeed includes a 64-bit timer
• timer module "0" is NOT "so blessed."   Yet (likely) one or more (other) Timer modules include that capability...

Deeper read/review of the MCU manual should announce which timers (if any) extend to your desired 64-bits.

You are too smart/experienced to, "fall to the trap of believing that every library function is included" w/in any one particular MCU.  Investigation should (always) trump "assumption."

I've done an extensive search and it appears that the TM4C1294 has nothing wider than a 32 bit timer.

Interestingly, the TM4C123 has a 64 bit timer. In every other regard the TM4C1294 is more capable! Wonder why this was done? I can understand limiting features that need I/O pins, because there are only so many I/O pins. But when it comes to timer widths, I would imagine it's a negligible price to pay. (While I'm at it, double the size I/O hardware buffers would be nice :-) ) 

My workaround has been to use the RTC functions HibernateRTCGet() for seconds and HibernateRTCSSGet() for subseconds. I've already implemented the RTC for other purposes, so the structure was already there. This is not as nice as a 64 bit wide timer since:

1) I need to ensure that HibernateRTCGet() does not increment before HibernateRTCSSGet is read (simple check)

2) The resolution of the HibernateRTCSSGet is only 1/32768 seconds, so the timing resolution is only 0.3 ms. Not a big problem if you want a millisecond resolution tick count, but not good if you want, say, a microsecond resolution. (A 64 bit wide timer would have given me a 8.3 ns resolution!)

You & I go back to "dinosaur days" - when 8 bit MCUs ruled.  And featured (maybe) 2-3 Timers.  It "IS" hard to believe that the superior MCU "ruled out" that wide Timer.

I'm all for your original "> 32 bit objective" - cannot you achieve that via detecting the 32 bit "roll-over" (setting a bit) and then simply reading that same timer to acquire the final 32 bits?   Such provides so much improved resolution - perhaps warrants your time/effort to implement & observe...

Superior is in the eye of the beholder. And I don't know how many applications can actually make use of a 64 bit timer nevermind requiring one. Still annoying if you were wanting one.

I second the use of a 32 bit timer. Even at ns resolution as long as you read it once a second or so overflow is easily dealt with even as a free running counter with no interrupts. Coarser scales can tolerate lower frequency reads of course.

Robert

Robert Adsett72 said:

I second the use of a 32 bit timer. Even at ns resolution as long as you read it once a second or so...

Absolutement mon ami.  

Poster appears "too quick" to abandon his 64 bit desire.   Each/every "Timer Roll-Over" may increment a var - yielding high resolution over a wide & flexible time-range...

RTC - as a FAR LESSER (band-aid) alternative - not so much...

I've already implemented the "HibernateRTCGet() for seconds and HibernateRTCSSGet() for subseconds" solution and it's enough for my current application. Being able to get a time is a very small portion of the overall application that I don't want to spend more time on it.

In retrospect, as cb1_mobile and Robert Adsett72 have suggested, it would have been better to use a 32 bit timer and build something bigger.

I'll complete my code to ensure I meet the timelines, but at a later date, I'll write a new routine that has a 32 bit counter trigger an interrupt once it reaches the terminal count and use this interrupt to increment a uint32_t. These will give me the 64 bit counter that I was after. It will give me microsecond resolution (actually 8.33 ns with my 120 MHz clock) and be good for 4874 years! Must remember to power cycle before the 4874 years are up :-).

(The current function is called TickCount(units), where units can be us, ms or s. So I can call TickCount(ms) and it will return me the milliseconds (since startup).)

I have, in fact, done such on another processor. Works well

Robert