• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 176 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC26X2R1: __TI_TIME_USES_64 do we need it? :)

kazola
Guru 18595 points
Part Number: LAUNCHXL-CC26X2R1

Hi everyone,

Our firmware application makes use of Seconds_set() and Seconds_get() API without __TI_TIME_USES_64.

As of it is now, by year 2038, what is Seconds_get() going to return?

I know we can add an offset somewhere to consider not 1900 but something newer as base time but I don't think this is the most elegant solution.

Do we need to use __TI_TIME_USES_64 and update our software and firmware?

Please, explain like I am five since time questions are so abstract.

Have a nice day.

  • +1
    TI__Mastermind 34960 points

    Hi,

    The implementation you choose would depend on how the timestamp from Seconds_get is used in your system.

    kazola said:
    As of it is now, by year 2038, what is Seconds_get() going to return?

    If the time value increments past what the underlying variable can hold in terms of bits, then it would roll over, and start from the base time (which the application had set with Seconds_setTime).

    kazola said:
    I know we can add an offset somewhere to consider not 1900 but something newer as base time but I don't think this is the most elegant solution.

    From a local perspective, I think this is a good option. If you have some kind of external time server in your system, then this can open up your options.

    kazola said:
    Do we need to use __TI_TIME_USES_64 and update our software and firmware?

    With that said, __TI_TIME_USES_64 is also an option, though with this option you would need to consider all other devices in your system. For example, if some other device in your system only supports 32-bit time, and this time from the CC26xx is passed to it, then there could be issues.

    Depending on how timestamps are used in your system, I'd say consistency is one of the most important considerations. 

    Thanks,
    Toby

  • 0 in reply to Toby
    Guru 18595 points

    Hi

    Thanks for your time and answers.

    In the current SDK, Seconds_get() returns an uint32_t so it seems this will be a problem by 2038. Please let me know if I am understanding this wrong.

    Just one last question, so when it rolls over, it does not start with 0 but at the value previously set with Seconds_set() ?

  • 0 in reply to kazola
    Guru 18595 points

    It seems this year 2038 bug only affects systems using signed int32_t for their datetimes. using uint32_t seems to get rid of it. I did a test and seems we are covered till 2106.

    Thanks. Let me know if I am understanding something wrong. Marking this thread as solved.