• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 401 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1310: Will RTC timing encounter Year 2038 problems?

Yolande Wang
Prodigy 540 points
Part Number: CC1310
Other Parts Discussed in Thread: SYSBIOS,

Hi team,

The customer uses the Seconds_set API in simplelink_cc13x0_sdk_4_20_02_07 to set the system time, and then uses localtime to obtain the year, month, day and other information. Has the Year 2038 problem been dealt with within this SDK? 

Thanks & Best regards

Yolande

  • +1
    TI__Guru* 83191 points

    No, I do not think so. If you look in the SDK, under C:\ti\simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\family\arm\msp432 and in the file Seconds.c, there are actually a warning:

    /*
 *  ======== Seconds_get ========
 *
 *  Note: This function is only valid until 2036-02-07 06:28:15 (TI Compiler)
 *      or 2038-01-19 03:14:07(GNU, IAR Compilers). At this time the number
 *      of seconds since 1900/1970 will cause integer overflow on 32-bit
 *      systems.
 */

    The same warning is not present in the Seconds.c file file for CC26xx (C:\ti\simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\family\arm\cc26xx)

    but I do not think that means that it is not a problem here, only that warning is missing.

    BR

    Siri

  • 0 in reply to Siri
    TI__Prodigy 540 points

    Hi Siri，

    Thank you for your reply.

    But i want to know how to avoid this problem.

    Best regards,

    Yolande

  • 0 in reply to Yolande Wang
    TI__Guru* 83191 points

    You cannot avoid the problem.

    If using unix time using a signed 32-bit int to store it, you will get an overflow.

    See Year 2038 problem - Wikipedia for details.

    If this overflow is critical or not for your system, I guess depends on what you are using the time and date for.

    If you simply has something that are just going to display the current time, you can do some kind of checking in the code too see if the data has wrapped (time is suddenly appearing to be BEFORE 00:00:00 UTC on 1 January 1970), and then do some kind of compensation to  this.

    I am sorry that I cannot provide you any solution for how to do this.

    Siri

  • 0 in reply to Siri
    TI__Prodigy 540 points

    Hi Siri，

    The customer said:

    The SDK reads the number of seconds starting from 1970 from the register, but when calculating, the number of seconds from 1900 to 1970 is added, and the calculation starts in 1900. In this case, the maximum number of 32-bit seconds is only 136 years. about. Something will go wrong by 2036. This is problematic for applications like mine that require timestamp conversion. I think you can add a macro definition (or do you already have this?), one starting from 1900 and one starting from 1970, so that it can be solved.

    Best regards,

    Yolande

  • 0 in reply to Yolande Wang
    TI__Guru* 83191 points

    As I said, we do not have a solution for this, and I do not think there are planned any fixed for this either.

    I think that on our newer devices, using RTOS 7 (CC13x2 SDK), this might already have been fixed using 64 bits instead of 32, but no SDK updates are planned for the CC1310.

  • 0 in reply to Siri
    TI__Prodigy 540 points

    Hi siri,

    The customer thinks it can be solved by modifying the code：

    Is it possible not to compensate for these 70 years, but to directly use the seconds starting from 1970 to calculate the current time? 32-bit variable 138 years, it should be able to remember more than 2100 years, or is there something wrong in my understanding?

    There is a macro definition of __ti__ (I don’t know what applications this macro is for)：

    Best regards,

    Yolande

  • 0 in reply to Siri
    TI__Prodigy 540 points

    Hi siri ,

    I think the 2038 issue time is calculated from January 1, 1970, and there is no issue of compensation. The SDK code uses uint unsigned integers, which should be able to be used until 2106, so there is no time overflow in 2038. Am I understanding this correctly?

    Best regards,

    Yolande 

  • 0 in reply to Yolande Wang
    TI__Guru* 83191 points

    The CC1310 SDK uses a 32 bits variable and will experience a problem in 2036-02-07 06:28:15.

    There will be an overflow, as explained/illustrated here:

    Year 2038 problem - Wikipedia

    It might be possible to get around this in the application, and the customer is also free to try to fix this in the implementation, but I will not be able to provide any more guidance and/or example code on how this can be done.

    If the customer think he have a solution, he simply needs to try to test it somehow.

    I am sorry that I cannot provide any more help on this topic.

    Siri