Current time jumping ahead of expiration time

Kernel
1

Hi All,

I am working on deriving remaining time for a timer via below formula-

Remaining time = xTimerGetExpiryTime( timer ) - xTaskGetTickCount();.

After reading documentation/code, I understand that timer module uses current tick count as a reference to derive expiration tick count. Since all the time are unsigned 32 bit integers, I don’t see any issue if my expiration time overflows as substraction will provide me correct value.

After reading below statement under API description, I understand that there is a possibility of current tick count to jump ahead of expiration time.

if the value returned by xTimerGetExpiryTime() is less than the current time then the timer will expire after the tick count has overflowed and wrapped back to 0. Overflows are handled in the RTOS implementation itself, so a timer’s callback function will execute at the correct time whether it is before or after the tick count overflow

But I don’t understand why will that happen when we are using current tick count as a reference to derive expiration time ?

If current tick count happens to jump ahead of expiryTime then doesn’t timer taking long time to expire(vs expected expire time) as it will have to wait for it overflow hence causing delay in timer callback function execution ?

I haven’t seen this happening on my system so far, but I am trying to understand its impact on my system. if there is a possibility for this to happen, then i am just wondering what could be the best possible way to deal with this situation ?

Thanks in advance

Regards,
Query1920

2

I think you might be misinterpreting the documentation. The timer will always expire on time. It can’t “miss” its chance and then expire in the next epoch of the 32-bit tick count.

The documentation you mention is referring to a condition when the intended expiry time is after the next tick-count rollover. The docs are explaining that the OS handles that situation automatically, with no special action required from you.

3

Thank you for explanation and correcting me.

My initial understanding was since expiry time is derived from current tick time, expiry time should always be ahead of current tick time except intended overflow/rollover scenarios. But i got confused when i read documentation and was wondering why will expiry time will be less than the current time.

With this understanding, i am assuming that except overflow conditions, there wont be scenarios where current tick count will have value greater than expiry time ?

Thanks

4

Yes that’s correct. (We are talking only about timers that are active).