RTC in RevolutionPi
- Simon Han (Deactivated)
- Dirk Conzelmann
Regarding duration, there are two a little bit confusing conceptions, clock and time needs to be clarified.
As stated on Wikipedia, RTC (Real-time clock) is used to keep track of the current time, is nothing to do with the clock described later. It focuses on the natural time (year, month, day, hour, etc.). Normally, the Integrated Circuit is used here to simulate the time flee and record the current time and date.
The clock (which is a clock signal) is a particular type of signal that oscillates between a high and a low state and is used like a metronome to coordinate actions of digital circuits. It focuses on its frequencies, and it is generated by oscillates.
The RTC needs a source of power, e.g. in PC a lithium battery is used to supply the RTC and store BIOS settings, etc.; in Revolution Pi a rechargeable super capacitor is used to supply the RTC, which is charged when the device is powering on, and will supply the RTC as the device powered off. In normal case, the Super Cap in Revolution Pi can be full charged in several hours by power on the device and can maintain the time for about 24 hours when power off. However, the lifetime will depend on the environmental conditions, like humidity, salinity, etc.
In contrast with Hardware, somebody maybe habitually thought that there is a software alternative one. But it seems that this is another misunderstanding in this field. The term Software-based RTC normally means the software (driver) is used to calibrate the RTC’s Hardware against drift, in other words, it seems just the accuracy of hardware is improved by software. Another relevant conception maybe is the system clock or system time, which is maintained by the operating system. This will be described in detailed later.
As mentioned in the previous section, the operating system (Linux) has a system time, which is initialized at system booting, and is essentially maintained by counting the pulse of the system clock.
The initialization of the system time can be either from the RTC hardware mentioned previously or from the network by e.g. NTP, etc. So, it’s not difficult to understand that the system time will be lost when both time sources are not available.
On Linux, there are some relevant services (daemons) and commands regarding the RTC as following:
a. date : mainly used to query or read the system time, showed in graph as command between User and system time [3]
b. hwclock : mainly used to query or set the time recorded in the RTC in the graph, with --get read the time, with --set set the specific time; with --systohc set the time of RTC from system time, and vice versa with --hctosys. [4]
c. timedatectl : functionally basically the same as the date command, but with better support of time zone, systemD, ntp,.etc… [2]
With the sub command set-time to set the system time, with sub command set-ntp to enable or disable the synchronization to ntp server. With sub command status to show the current time and setting, other sub commands are related to time zone, which are not described in detail here.
Because of the enhancement of the ntp functions, the sub command set-time will be fail if the system time is synchronized to the NTP server, which is not the case for command date.
To further clarification, the output of timedatectl status is explained:
pi@RevPi8173:~ $ timedatectl status
Local time: Mon 2019-12-02 13:51:17 CET --- time in local time zone (system time)
Universal time: Mon 2019-12-02 12:51:17 UTC --- UTC time
RTC time: Mon 2019-12-02 12:51:18 --- time in RTC
Time zone: Europe/Berlin (CET, +0100) --- time zone
Network time on: yes --- set-ntp enabled
NTP synchronized: yes --- time synchronized
RTC in local TZ: no --- time zone in RTC
d. systemd-timesyncd.service : a systemD service works as a daemon with the NTP (Network Time Protocol) to synchronize the system time with remote NTP service. The corresponding configuration files can be found with man timesyncd.conf.
As shown in the picture, the following actions can happen regarding the specific scenario or operations.
· The Linux gets time from RTC (hardware) and stores it as system time, and it is updated by interrupt from Oscillator.
· User can get the stored time string from RTC with hwclock --get through device node /dev/rtc, and set it with hwclock --get. Anyhow, the read operation to RTC is always done for both.
· User can use date to set only the system time
· User can also use timedatectl to set the time. However, meanwhile, both the RTC and system time are updated.
· At system booting or periodically, the system time is synchronized with the NTP server on the network when this function is enabled by the user.
How to debug the problem with RTC & time?
For convenience, some tips to locate the RTC-related problem will be described here.
In most cases, it appears as the time is not correct, showed with command date or timedatectl. Then the following checks can be done to find some clue of the problem.
Have a check of the output of timedatectl, considering with the meaning of each item, find out whether it’s logical regarding the context as you know (configuration, connection,.etc.). If the item RTC time is n/a, one possibility is revpi-factory-reset has not been done correctly.
Have a check of the kern.log with dmesg, if there are rtc-pcf2127 error logs existed like the following, it’s probably because the super cap is used out. Power on it, and let it be charged for a while (several hours) and reboot will be fine.
[ 10.528100] rtc-pcf2127 1-0051: pcf2127_set_datetime: err=-5
[ 10.528260] rtc-pcf2127 1-0051: pcf2127_get_datetime: read errorHave a check of the network connection to NTP server, whose URLs can be found in timesyncd.conf. Ping the NTP Server from the device to see whether the network connection is available.
Take a look at the current time of the device, whether it’s 1970-xx-xx or 2016-xx-xx…. If it is in 2016, probably it is caused by discharge of RTC. And it is quite not common in Linux now that the time goes back to 1970.
Check the output of executing hwclock -w or timedatectl status to trigger the reading of the RTC, if it responds message containing “Invalid argument”, it most likely caused by reading the RTC failed, which can be caused by one of two reasons:
a. Something happened with the Oscillator in RTC, which you would see a warning log in kern.log as "oscillator stop detected, date/time is not reliable"
b. The time stored in RTC is not a valid time. e.g. earlier than 1970
Currently, no information about further determined reasons for these problems, some analysis should be done according to use environment.Check the NTP time synchronization information with the command systemctl status systemd-timesyncd
pi@RevPi1024:/etc $ systemctl status systemd-timesyncd
systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
`-disable-with-time-daemon.conf
Active: inactive (dead) since Fri 2019-11-29 14:57:44 CET; 3 days ago
Docs: man:systemd-timesyncd.service(8)
Process: 2329 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=0/SUCCESS)
Main PID: 2329 (code=exited, status=0/SUCCESS)
Status: "Idle."
Nov 03 18:17:38 RevPi1024 systemd[1]: Starting Network Time Synchronization...
Nov 03 18:17:38 RevPi1024 systemd-timesyncd[2329]: System clock time unset or jumped backwards, restoring from recorded timestamp: Fri 2019-11-29 14:51:23 CET
Nov 29 14:51:23 RevPi1024 systemd[1]: Started Network Time Synchronization.
Nov 29 14:53:15 RevPi1024 systemd-timesyncd[2329]: Synchronized to time server 217.91.44.17:123 (0.debian.pool.ntp.org).
Nov 29 14:57:43 RevPi1024 systemd[1]: Stopping Network Time Synchronization...
Nov 29 14:57:44 RevPi1024 systemd[1]: Stopped Network Time Synchronization.
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
References: