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.

AM623: AM623 RTC time settings for the future will be saved immediately, but for the past will not be saved immediately

Part Number: AM623

Tool/software:

Hi,

I encountered a problem when using RTC on AM623.
the time of the board is 2025, if I set the time point to 2026 and then disconnect the power, the time will be updated after powering on again.

~# date
Thu May 15 16:00:04 UTC 2025
~# hwclock
2025-08-08 08:20:27.177775+00:00
~# date -s "2026-6-6 6:6:6"
Sat Jun 6 06:06:06 UTC 2026
~# hwclock -w
~# hwclock
2026-06-06 06:06:13.808466+00:00

But if I set the time to 2024, the time of RTC will be restored to the time of 2025 after power off and on.

~# date -s "2024-4-4 4:4:4"
Thu Apr 4 04:04:04 UTC 2024
~# hwclock -w
~# hwclock
2024-04-04 04:04:12.374590+00:00
~# date
Thu Apr 4 04:04:17 UTC 2024

In this case of setting to the past time, the time will be set normally only after reboot or poweroff .

~# date
Fri Aug  8 08:09:02 UTC 2025
~# date -s "2023-3-3 3:3:3"
Fri Mar  3 03:03:03 UTC 2023
~# hwclock -w
~# hwclock
2023-03-03 03:03:10.332103+00:00
~# date
Fri Mar  3 03:03:12 UTC 2023
~# poweroff

The chip we use is rtc-pcf8563. I saw someone say that for security or system consistency reasons, the RTC driver of some embedded platforms restricts the time from being called back, unless it is in the shutdown process (such as poweroff,reboot).

Is this really the case? Is there a way to write it immediately?

  • Hello,

    It looks like rtc-pcf8563 is manufactured by NXP. From the TI side, we would just provide the low level I2C driver for interacting with the RTC over I2C. The actual driver for interacting with the peripheral would come from NXP. If you have any questions about this NXP peripheral or the NXP driver, please reach out to NXP.

    Regards,

    Nick

  • Hi Nick

    It's not a problem with the RTC driver layer, it seems to be caused by system initialization.

    Below is my test log. At the beginning, the system time was 2015-1-5. I set it to 2008-8-8, and the display setting was successful.
    Then I turned off the power and turned it on again.
    However, after the system started up, the time displayed was still 2015-1-5, but the time read by the RTC driver in dmesg was 2008-8-8.
    I don't know what changed the time configuration before the system started. And it can still remember the date value before setting it.
    Do you have any suggestions on this?

    ~# date
    Mon Jan  5 01:07:36 UTC 2015
    ~# date -s "2008-8-8 8:8:8"
    Fri Aug  8 08:08:08 UTC 2008
    ~# hwclock -w --update-drift
    ~# sync
    ~# date
    Fri Aug  8 08:08:12 UTC 2008
    ~# hwclock
    2008-08-08 08:08:16.335551+00:00
    ~#
    
    Power off and restart
    
    ~# date
    Mon Jan  5 01:06:12 UTC 2015
    ~# hwclock
    2015-01-05 01:06:32.227769+00:00
    ~# dmesg | grep rtc
    [    0.986352] rtc rtc0: invalid alarm value: 2008-08-08T32:58:00
    [    0.992483] rtc-pcf8563 0-0051: registered as rtc0
    [    0.998561] rtc-pcf8563 0-0051: setting system clock to 2008-08-08T08:08:43 UTC (1218182923)
    ~#

  • Hello Stephen,

    This really feels like a generic "how does the Linux clock work on any Linux processor" question, not a "how does TI-specific code or hardware work" question. As a reminder, we cannot support general questions about how to use Linux on these forums, only questions that are specifically about TI software or TI hardware.

    First, you should verify what clock source is being used by "date". It is possible that your system is using a different clock source than the external RTC. Then you can select which clock source you want to use.

    Since this is a "generic Linux" question, I cannot offer much help here. I would suggest searching around the web for threads like this:
    https://unix.stackexchange.com/questions/662571/how-can-i-verify-the-clocksource-in-my-system

    Regards,

    Nick

  • Hi Nick,

    Thanks, the problem has been solved. It was caused by the timestamp file.