What happens when the 32bit HAL uwTick timer variable overflows after 49 days?

[LMorr.3]

I'm looking to use HAL_GetTick to track how many ms have lapsed. Unfortunately, it uses a 32bit uwTick variable which will overflow in 49 days. My device may be on more than 49 days, so I was planning on adding a uint64_t ms_passed and increment it at the same place where HAL_IncTick() for my TIM7's callback freeRTOS setup. Am I doing this right?

[KnarfB]

Sounds good.

KnarfB

[Michal Dudka]

There is nothing wrong with Hal tick counter overflow. You can reed more info from Nick Gammon:

https://www.gammon.com.au/millis

[Tesla DeLorean]

What actual resolution do you need?

If you counted every 1000 ms in the SysTick_Handler, you could have a second counter good to 49710 days (136 years). In other words keep all the HAL_GetTick dependencies, and have a long-count

The millisecond tick is design for relatively short timeout duration, and can handle the 49 day wrap with those using appropriate unsigned math.

For Time/Date stuff I've historically used the Windows 64-bit FILETIME, and convert that to SYSTEMTIME when needed, that's good for 30,000 years, and I think I validated my leap year stuff out about 3,000

[KnarfB]

your reference says:

"If you are using millis() you cannot time more than 49.71 days, ..., without extra code to detect the wrap-around."

But that's what the OP wants.

hth

KnarfB

[Michal Dudka]

May be. His question didn't seem so clear to me. Maybe he's just worried what happen when tick counter overflow like in "title question". But his suggested solution - adding another 64bit tick counter must be handled with care. He must read that 64bit value atomic way (reading must not be interrupted by IRQ routine where is that counter incremented).

[LMorr.3]

I now see how the unsigned wrap will not be an issue. Thanks for that info.

I don't need 1 beat to last 49 days, so from what I understand, I can just use a 32bit counter in SysTick_Handler, or re-use the 32bit sytem counter uwTick since I now understand how the wrap will not be an issue with my timestamp tracking.

[Tesla DeLorean]

Yes, well I think the question was one of counting/dealing with elapsed time beyond 49 days, for systems that may be expected to run continuously for years. I don't think it's timeouts of 50+ days, or the wrapping of shorter delay as the count rolls over. Most of that broken code has been purged, but there's plenty of people who seem to want to reintroduce such code.

SysTick needs to have the highest priority and be preemptive as the bulk of the code both in normal execution and call-back/interrupt context has so many expectations that the count will advance.