Things are constantly moving forward in Raspberry Pi land and setting up a Real-Time Clock (RTC) on the RPi is no exception. For the old way of doing things see this page. For the new way under Jessie / Stretch or Buster read on. Although this page describes setting up the RTC on Sleepy Pi 2, this same method can actually apply to any supported RTC - you just need to change the overlay as explained below.
If you have used the Sleepy Pi setup script you can skip straight to "Detect the RTC".
The first order of business is to setup / enable the i2c bus on the Rpi. You can do this by uncommenting a line in config.txt. Here are the magic incantation in a command window:
scroll down until you find the line:
and uncomment by removing the # then exit & save (Ctrl-X then y). This will enable the i2c bus (well it will on your next reboot).
Next install the i2ctools by typing:
This will install some handy utilities for the i2c and then reboot:
To give you a warm cuddly feeling, it’s always a good idea to check the i2c bus with this command:
if you’ve got one of the original Raspberry Pi’s, then the bus was 0 so you would type:
You should see something like this:
If you are using a Sleepy Pi 1, then the listing is the same but without the 0x24 listing. If you see "UU" instead of "68" it means that the RPi has loaded a driver for it and it is in use - see below.
To tell the Raspberry Pi that we have a hardware clock, we need to add the following line to config.txt.
scroll down to the bottom and add the line:
then exit and save (Ctrl-X then y). That's a comma, not full stop, between i2c-rtc and pcf8523! And it's a "dash" not "equals" between i2c and rtc!
BTW: if you have another RTC that you are trying to get working and want to know whether out is supported and what the overlay is called, have a look here and see if yours is listed.
Now comment out some lines in hwclock-set:
and comment out the following lines (using the #).
It's also a good idea to comment out all the --systz lines too (as shown below). These update the RTC from the RPi and can cause issues.
then exit and save (Ctrl-X then y). This will stop that script exiting early and will update the clock on boot.
Next reboot and the configuration is done.
To read the time from the hardware RTC you can issue the following commands. To read the time:
To copy the time from the RPi system to the hardware RTC (RPi-> RTC):
To copy the time from the hardware RTC to the RPi system (RTC - RPi):
You can directly set the time of the hardware RTC with:
If you set-up the RTC as decided above then by-and-large things should be tickety-boo. If you are connected to a network, the RPI will go and get the time from the Net and you can then copy it across to the RTC with a "sudo hwclock -s". If we left the --systz uncommented in the /lib/udev/hwclock-set it would even do this automagically (the --systz is shorthand for sys to rtc). However, I'm sure you know there's a "but" coming….
But, the RTC is a funny beast and when you disconnect the RPi from the network strange things can occur which invariably manifest themselves as corrupting the time on the RTC. Pinning down why this occurs is quite arcane, but what is for sure, is that it is caused by the RPi looking for a time synchronisation source and when it doesn't find it, it decides to ruin everyone's fun and corrupt the RTC. This is very bad news if you are relying on your RTC to trigger a wake-ups as we do with Sleepy Pi.
So basically persecute any automatic RPI to RTC writes with extreme vengence.
The first step, is to stop the RPi writing to our RTC at boot. If you have followed the instructions above, you will have commented out the --systz lines in /lib/udev/hwclock-set.
Next the mechanism for updating the time over the network is NTP or Network Time Protocol. Disable this by doing:
These two steps should do the trick, but if it's also a good idea to disable the "fake hwclock" (after all, we have a real one!).
Disable this by doing:
Whilst working with the RTC, you may come up against a few things that will bite you. Here’s a couple:
The image below shows that if you don’t use sudo, you’ll get an (not too helpful) error shown below.
This can look really throw you off track when you are configuring the RTC because it makes you think that you haven't configured it properly.
If you run:
after you have configured the RTC in the system then it appear as UU in the map.
This can be pretty disconcerting, but is perfectly normal. It just means that the address 0x68 has been reserved for system use.
If you want to play around with settings on the RTC with the i2c command line tools, you won't be able to once the System is using it. You can either use the command line tools OR load the System driver, but not both 😥
This section gives you a few tools and techniques to check on...when RTC's attack.
Remember, with Linux there are always multiple ways of doing the same thing - this can confuse the *%$^ out you. The tips listed below can virtually all be done in other ways. It drives me to distraction...
You can check that the pcf8523 driver is loaded without a problem by looking to see whether it was loaded at the last boot:
There is a very nice little command that lets you check on the state of the clocks:
You can see from the above image that there is a line marked "RTC Time" - if you haven't got the RTC setup, then this line will be blank. You can also see that the RPi time - shows up in Local and Universal is initially different from the RTC time before a "sudo hwclock -w" syncs the 2 together.
You can also do a simple read of the RPi Clock with:
and the RTC with:
To set the RPi clock you can do:
You can also enable the ntp service and get the current time with a sudo systemctl restart ntp.service. If you are feeling adventurous, then here's another way:
and similarly "false" to disable.
You can check the state of various services with the systemctl command. Here are some examples:
You can also turn them back on with:
If you are troubleshooting strange clock syncs, the following command trawls the log for when the system updates the clock:
The whole clock thing under Linux is a complete Dog's Breakfast. The timesync service also does a similar job to NTP. Why have 2? You tell me. Whenever I've looked, it appears to be disabled but you may need to check this puppy out if you are having problems:
and if is is active, stop it:
Your email address will not be published. Required fields are marked *