AM3352: Year 2038 problem

Koichiro Tashiro

Part Number: AM3352

Hi,

I got a question from my customer using AM335x.
They are using:
SYS/BIOS 6.35.4.50
TI ARM Compiler v5.1.6

Customer wants to know if they are impacted by year 2038 problem.
2038 Jan. 19 problem
2038 Apr. 23 problem
or other problems if exist.

If they are impacted, could you tell me how to avoid it?

Thanks and regards,
Koichiro Tashiro

over 4 years ago

0 RonB over 4 years ago

TI__Mastermind 30526 points

I'm sorry for the delay in responding. I am researching this issue, but I need to seek advice from others and it will take a little more time. I will provide an update early next week.

Thank you.

0 Jianzhong Xu over 4 years ago in reply to RonB

TI__Guru 59095 points

Hi Tashiro-san,

For clarification, what does your customer mean by "2038 Apr. 23 problem"? My understanding is that the year 2038 problem happens on Jan 19, 2038.

Does your customer's application use date information for any purpose? If it does, then I think they will likely be impacted by the year 2038 problem. Do they use any function from SYS/BIOS to get date (or second counter)? If they don't use date information in their application, the I don't think they will be impacted by the year 2038 problem.

Thanks,

Jianzhong

0 Nick Saulnier over 4 years ago in reply to Jianzhong Xu

TI__Guru** 101410 points

FYI for future readers:

This thread handles year 2038 on AM335x RTOS. We are addressing the year 2038 question on AM335x Linux on the thread over here:
(+) AM3356: Inquiry about RTC: " Year 2038 problem" - Processors forum - Processors - TI E2E support forums

Regards,

Nick

0 Koichiro Tashiro over 4 years ago in reply to Jianzhong Xu

TI__Mastermind 22945 points

Hi Jianzhong,

Jianzhong Xu said:
For clarification, what does your customer mean by "2038 Apr. 23 problem"?

According to customer, it is related problem happens in particular system using "Julian day".

Jianzhong Xu said:
Does your customer's application use date information for any purpose?

Customer does not check it. It takes time to check it, so customer wanted to know if TI products are impacted or not first.
So I understood customer's system will be impacted if date information is used, right?
Is there any way to workaround the issue?

I found below thread about TI ARM compiler.
https://e2e.ti.com/support/tools/ccs/f/code-composer-studio-forum/707351/compiler-am4379-about-year-2038-problem?tisearch=e2e-sitesearch&keymatch=year%25252525202038#
and below Wiki link from the thread:
https://processors.wiki.ti.com/index.php/Time_and_clock_RTS_Functions

Is this applicable for AM335x as well?
SYS/BIOS library, etc. are not rebuild using these 64bit parameters?

Thanks and regards,
Koichiro Tashiro

0 Jianzhong Xu over 4 years ago in reply to Koichiro Tashiro

TI__Guru 59095 points

Let me do some more research on this and get back to you early next week.

0 Jianzhong Xu over 4 years ago in reply to Jianzhong Xu

TI__Guru 59095 points

Koichiro Tashiro said:
Customer does not check it. It takes time to check it, so customer wanted to know if TI products are impacted or not first.
So I understood customer's system will be impacted if date information is used, right?
Is there any way to workaround the issue?

TI's Processor-SDK RTOS itself (including BIOS kernel) does not have dependency on date information and thus is not impacted. The SYS/BIOS provides API to set and get number of seconds since year 1970. These APIs return 32-bit unsigned integer as documented in BIOS Seconds Module API, which actually represents date range 1970-2106. Therefore these APIs won't cause 2038 problem if they are used properly in your customer's application.

Koichiro Tashiro said:
Is this applicable for AM335x as well?
SYS/BIOS library, etc. are not rebuild using these 64bit parameters?

Yes, GCC or TI compiler which supports 64-bit time_t should work for AM335x as well. SYS/BIOS can be rebuilt with those compilers.