STM32 with 64-bit Timer

[Md_Aslam]

Can anyone suggest me some STM32 or any other Microcontroller with 64-bit of Timer and Highest Clock Frequency?

[waclawek.jan]

> 64-bit of Timer

There is no 64-bit timer in any STM32 AFAIK.

JW

[GwenoleB]

Hello @Md_Aslam​,

Indeed there is no STM32 embedding a 64-bits timer.

Can you clarify for which purpose a 64-bits timer is required and which frequency do you target?

It's possible for some of our deviced to cascade timer by using internal trigger from a master to slave timer. This feature could fit with your needs.

Best Regards,

Gwénolé

[Md_Aslam]

Actually I am trying to make a "time interval measurement device" using STM32, where I will try to measure the delay of two signals applied to the GPIO pins of the STM32.

Delay may vary from few ns to approximately 1s, in my case it is coming out to be 500ms (measured with Keysight-53230A)

I have STM32 NUCLEO-L073RZ with 32MHz clock and timer of 16-bit, the problem is measuring range achieved by these timers are less:

For 16-bit timer with 32 MHz clock

Measuring range --> (2^32)*(1/32MHz) --> 2.04ms

Resolution --> 31.25ns

Here Resolution is indirectly proportional to the Measuring range, so with fixed value of Timer/counter, if I increase the clock frequency to achieve the higher resolution I will have to compromise with the Measuring range. So I think solution is to increase the size of Timer instead.

PS: I know Timer with 40 to 50-bit will also work, But I am not able to find those STM32 with these Timers.

PPS: According to me the alternate and very effective solution for this problem will be to use TDCs for this application, But there are no TDC with small size and measuring range up to 1s, although resolutions are much better in these TDCs like TDC7200 and AS6500.

[GwenoleB]

Hello @Md_Aslam​,

Firstly, there is some feature you can use to save some clock cycles. By configuring the timer on input capture mode, each time a rising/falling/both edge is detected then the counter register is copied into CCxR register. Then, the CPU will never manage the GPIO to read the timer counter register. This feature will not change the resolution (frequency dependant).

For the next point you raised, if the measuring range is too short there is a trick but there is some constraints. By using the overflow feature, timer can be seen as infinite counter where each entire lap is equal to 65536 clock cycles in 16-bits mode.

IF the external signal is almost equal to a same frequency and has a low variation between two consecutive periods, the number of entire counter lap the timer does is known. This number of lap is given by the ratio of external frequency to measure and the counter frequency:

CNT_total=F_TIMER/F_SignalHz  →Nb_lap=(CNT_total)/65536

This feature works since the external signal period variation doesn't exceed one entire counter period (in your case 2.04ms).

If this trick doesn't work for you, then we can have a look an a MCU with higher frequency using input capture mode, or try to extent the measuring range by cascading multiple timers.

Best Regards,

Gwénolé

[Md_Aslam]

Once I gave a thought to cascading the Timer, but I faced one problem..

That is, this approach will definitely work beyond 32-bit Timer, but in STM32, is there any data type which can store value of size more than 32-bit? because when I used uint64_t the compiler gave me the error!

PS: I searched a lot on internet and found that the size of the data type is compiler dependent not the microcontroller architecture dependent, as STM32 is a 32-bit architecture but still we can use 64-bit variable in it.

But I don't know how to use a 64-bit (say uint64_t) value in 32-bit STM32.

[Clifford1]

---

@Md_Aslam wrote:

when I used uint64_t the compiler gave me the error!

Then your question is an X-Y problem - perhaps you should ask about the error with that solution.  What compiler and what was the error?  That error is likely more easily resolved than changing MCU for a non-existent 64-bit hardware timer!

All timers can generate an overflow interrupt, the solution is to use that to increment a counter that you then use as the upper 32 bits of a 64 bit counter.  No need for timer cascading, which would be an unnecessary and profligate use of hardware for this purpose and offers no significant benefits for this application other than lower interrupt overhead.

So given for example a TIM2 configuration counting 0 to 0xFFFFFFFF with overflow interrupt enabled, then;

#include <stdint.h>

static volatile uint32_t overflow_count = 0 ;
void TIM2_IRQHandler(void)
{
 overflow_count++ ;
}

uint64_t getTimerCount( void )
{
 uint32_t count_lo = 0u ;
 uint32_t count_hi = 0u ;

 do 
 { 
 count_hi = overflow_count ; 
 count_lo = TIM2->TCNT ; 
 } while( count_hi != overflow_count ) ; 

 return ((uint64_t)count_hi << 32) | count_lo ;
}

The reason for the while loop is because the assignment of count_hi and count_lo is non-atomic and it is possible for overflow_count to be incremented between the count_hi and count_lo assignment causing and incorrect value to be generated.  The loop ensures consistency between the two values (i.e. that they refer to the same overflow period). 

Generally the loop will run once.  Rarely it will run at most twice, but those rare occasions will save you from infrequent but really difficult to track down bugs.

You would have a similar consistency issue even if you use cascaded timers, and would use a similar solution.

Note that if `uint64_t` truly does not exist (more likely you failed to include stdint.h), then understand that it is simply an alias for `unsigned long long`.

[gbm]

With STM32H730 or similar uC and 32-bit timer (TIM2/5/23/24) you may obtain < 8 ns resolution and 32 second max. delay. Why would you need a non-existent 64-bit timer?

[Md_Aslam]

Thanks for the suggestion I will definitely consider this uC for my project.

But due to heavy shortage of uC nowadays I don't think it will be available easily.

[Piranha]

> For 16-bit timer with 32 MHz clock

> Measuring range --> (2^32)*(1/32MHz) --> 2.04ms

You write 2^32 and then calculate with 2^16. For 2^32 the range is 134 seconds! Your calculation was broken and you didn't even check and think about it, but instead started "researching" something unnecessarily more complex...

On STM32G4 with a 32-bit timer running at the maximum 170 MHz you can get 25,3 s range with a 5,88 ns resolution. Yes, it's the fastest STM32 series for such purpose.

[MHank.1]

You might be able to link 2 32 bit timers together to make a 64 bit time as on the STM32F722ZE with a max freq. of 180MHz.

 

An example of linking 2 16bit timers together is given in;  ARM Tutorial Part 2 Timers