Raspberry pi 3 RTC

Now that it's time to add an RTC to the Pi like I did with the Beagle Bone, I can now enjoy the much greater wealth of options for the Pi. I can also finally learn the correct way to install one using Device Tree since Raspian has gone that way like everyone else.

It turns out that the most common RTC is a tiny single-board, single chip solution that takes advantage of how the first four adjacent pins on the GPIO header are power, ground and i2c bus. Links:

The RTC board that I ordered. It seems that there are a couple of manufacturers doing this design and hard to tell who was first: https://www.sunfounder.com/ds3231-real-time-clock-module.html

One setup guide: http://www.raspberrypi-spy.co.uk/2015/05/adding-a-ds3231-real-time-clock-to-the-raspberry-pi/

Another setup guide: https://trick77.com/adding-ds3231-real-time-clock-raspberry-pi-3/

Here is a nice guide that shows configuration methods for both the old (modules) method and the new (Device Tree) method. It mentions steps for disabling the fake hwclock but it doesn't look like it shows the full procedure: http://www.bashpi.org/?page_id=500

Basically all the good guides are from this one google search: https://www.google.com/#q=sunfounder+ds3231+how+to+install

Having followed those installation guides, somehow it was coming up after rebooting with times that were only close to the current time although not reset to any particular default. It really seemed like the "fake hardware clock" was stepping on the rtc chip's time or something like that.

This site seemed to have the magic bullet for turning fake hwclock off, a beautiful single command which somehow alters all the rc.d files that had time setting stuff: http://forum.openmediavault.org/index.php/Thread/8770-RPi-2-RTC-module-from-unruly-Stepchild-to-Wunderkind/?pageNo=3

Specifically:

update-rc.d -f hwclock.sh remove

Unfortunately, after a few tests that seemed to show that the RTC was working, it stopped working. At first it looked like some tests that I had donewith an alternate power supply for the Pi might have damaged something, however a brand new sunfounder RTC continued to behave the same way. Upon reboot, the time would be set to 9:00 Dec 31, 1969 (upon reflection, this likely to be just midnight Jan 1 1970 GMT as viewed from EST although that doesn't quite add up right it should be 4 hours off not three), and attempting to read the hardware clock manually after a reboot resulted in the message "The hardware clock register contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095)."

A review of the messages file in /var/log seems to show that the chip is being registered as the hardware clock during bootup without any problems. /dev contains a device rtc0 with a simlink from /dev/rtc to /dev/rtc0.

A google search for the date 12/31/1969 shows a few people experiencing a similar problem on a variety of platforms with a variety of RTC chips.

A google search for the register message produces several other hits, one of which looks promising:

https://www.raspberrypi.org/forums/viewtopic.php?p=690492

Some suggestions that seem good that I haven't done yet are to turn off ntp:

update-rc.d ntp disable

fix /lib/udev/hwclock-set according to this link: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=16218&start=25

Also look for marcus15's post near the bottom of this page: https://www.raspberrypi.org/forums/viewtopic.php?p=690492

Furthermore, the same genius who began figuring things out in the above threads, marcus15, has worked through how to set things up for the Jessie distribution of Raspbian (which is what I have, so this applies in particular):

https://www.raspberrypi.org/forums/viewtopic.php?p=692662#p692662

The next to last entry on this page, by pemst, covers a lot of the same steps listed in marcus15's answer with some slight variations in technique: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=16218&start=100

Following the instructions in marcus15's and pemst's posts solved the problemThe problem seems to stem from a timing problem in the original configuration files in Raspbian, in that the usual setting in the hwclock.txt file to read the time from the hardware clock on boot is not being called before some code that decides that the time hasn't been read from the hardware clock and then writes crap to the RTC. The solution, aside from turning off fakehwclock and ntp, is to create a new service that reads the hwclock and then enable that service because apparently services are set up earlier in the boot sequence. Cutting and pasting from the forum threads above:

basic setup: Edit /boot/config.txt to include the following (notice unusual setup of i2c baud rate which I haven't seen anywhere else but which looks like a useful thing):

dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds3231
dtparam=i2c_baudrate=400000

Next create a service script named hwcock-start.service in /lib/systemd/system by copying hwclock-save.service and editing it to look like this. Note that the call to hwclock is more fancy that normal, with the -D option to print diagnostic to the log files in the event of a problem and the --hctosys option to use the local time zone.:

[Unit]
Description=Synchronize Hardware Clock to System Clock
DefaultDependencies=no
After=sysinit.target

[Service]
Type=oneshot
ExecStart=/sbin/hwclock -D --hctosys

[Install]
WantedBy=graphical.target multi-user.target

Then execute the commands to enable the new service. NTP off is shown below also for good measure.

sudo systemctl daemon-reload
sudo systemctl enable hwclock-start
sudo systemctl disable ntp

Then set the system time and save it to rtc0 and on the next boot the time is read correctly from the RTC.

sudo date -s "MM/DD/YYYY hh:mm"
sudo hwclock -w -f /dev/rtc0

Linux write message to log file from .service

As part of trying to debug the .service that I set up for installing the RTC chip on my BeagleBone at boot time, I was interested in writing messages to the Linux system logs from the shell script that it called. This turns out to be fantastically easy; there seems to be a couple of different commands that can be used, I went with the 'logger' command, as described in this link:

http://www.cyberciti.biz/tips/howto-linux-unix-write-to-syslog.html

Notes from compiling a kernel module from scratch

Found the debian SD image for BeagleBone that I started testing with so long ago. It's probably obsolete by now, but at least I know that it works.

Its name is bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img

Used Win32DiskImager to write it to a blank 4G SD card from AdaFruit.

Beaglebone booted to LXDE desktop after a worrying 45 second pause (It might have been setting up the ethernet connection)

perform apt-get update

sudo apt-get update

Update Tkinter just because

sudoe apt-get install python-tk

start python, verify tkinter installed to make sure that the last installs worked.

$ which python
$ python
import os
import Tkinter
^d

get my kernel version:

$ uname -r
3.8.13-bone70

attempt to get the source tree headers:

$ sudo apt-get install kernel-headers-$(uname -r)
E: Unable to locate package kernel-headers-3.8.130bone70
E: Couldn't find any package by regex 'kernel-headers-3.8.13-bone70'

$ sudo apt-get install kernel-headers
E: Unable to locate package kernel-headers

Try searching the cache for anything that might be what I'm looking for:

$ apt-cache search kernel | grep headers
$apt-cache search headers | grep bone70
linux-headers-3.8.13-bone70

Note: from above searches, I discovered that the cache had headers up to and probably past bone79.
trying again to get the source tree headers:

$ sudo apt-get install linux-headers-$(uname -r)

Worked great.

Download hello.c and Makefile from google cached version of this site (which seems to be not responding right now for some reason) http://www.cyberciti.biz/faq/add-remove-list-linux-kernel-modules/

Copy Makefile and hello.c to new folder under /home/debian, cd to folder, run 'make'. Compiled .ko file as promised.

Run the following commands. Kernel module seems to be installed, although there is an extra message in the /var/log/messages file saying: "hello: module license 'unspecified' taints kernel"

$ modinfo hello.ko
$ sudo insmod hello.ko
$ lsmod
$ rmmod hello
$ tail -f /var/log/messages

Pulled raw rtc-pcf8563.c file from https://github.com/jeffegg/beaglebone/tree/master/drivers/rtc and tried to put it in its own directory under /home/debian with the Makefile from the hello example, changing the name of the object to compile, got some compile errors. Specifically it doesn't like THIS_MODULE and the module property declarations at the end.

The makefile at https://github.com/jeffegg/beaglebone/tree/master/drivers/rtc has a bunch of options for compiling other things like rtc-lib.o, rtc-core.o, all of which seem like I might need them.

Looking at the linux headers directory that I downloaded earlier, I am surprised to find the exact same makefile under /usr/src/linux-headers-3.8.13-bone70/drivers/rtc!!!! This may indicate that I might be able to find the kernel module in the source tree and just build it after all. The question is how to get the source tree. After a lot of fiddling, trying:

$sudo apt-get install linux-source

This seems to be getting me the 3.2 source instead of the 3.8 for unknown reasons, but that might be sufficient to get a drivers build directory that matches the drivers header directory.

BeagleBone installing PCF8563 RTC

I ordered the Waveshare "Misc Cape" which uses the PCF8563 RTC chip with an I2C interface like all of them. Waveshare's online documentation is unhelpfully brief regarding how to install drivers for it. They offer a fully compiled Angstrom distribution with their drivers but since Debian is working out so well for me on my project I was hoping to try to find a way to install drivers for Debian. At the bottom of their wiki for this cape there are a bunch of links, some of which seem to be source code and other documentation, but it's not clear what it all is.

http://www.waveshare.com/wiki/MISC_CAPE

One of the links turns out to be to two SD card images, one of which is a fully compiled Debian image that has the drivers for the PCF8563 chip built in, however when I downloaded and tried it I found that although the RTC driver seemed to work well there were other issues with the distro that have to be overcome:

http://www.waveshare.com/wiki/MISC_CAPE_Image

There are other links on the same wiki page that I'm still trying to figure out. The "User Manual" link is just to a PDF of the wiki. The Schematic is helpful but really the cape is quite simple and the schematic is a single page. The Test Code link is to a zip file named XXX_CAPE_Angstrom_API.7Z which seems to contain a mix of C programs and compiled programs which don't have anything to do with the PCF8563 and furthermore seem to be for the Angstrom kernel. The section labelled "Kernel" seems to have several different source code trees for both Angstrom and Debian kernels, presumably with driver code but at the moment I still don't know how my way around kernel source code or how to compile kernels although it looks like I'm going to have to learn. The section labeled "Kernel_config" also seems to have to do with compilation so I will have to become smarter to even understand what it is. I have absolutely no idea what the link labelled "Cross-compilation toolchain" is even referring to. Under Source Code there are several links to zip files but some obviously have nothing to do with the RTC chip (like "wifi" and "mjpg-steamer") and the one link labelled "driver" is to a zip file that just has one c file with code that also doesn't seem to have anything to do with the RTC chip. Of the three links under "Documentations" the first one "Porting Drivers" actually mentions the RTC chip but the compilation instructions are like greek to me. The link for "Porting Kernel" mysteriously seems to be about building a Ubuntu kernel, and these instructions are also opaque to me at the moment.

Looking for a shortcut to figuring out the poorly documented materials on the Waveshare wiki, I started looking at the following tutorial, which showed how to interface a different chip that is on Adafruit's RTC stamp to BeagleBone.

https://learn.adafruit.com/downloads/pdf/adding-a-real-time-clock-to-beaglebone-black.pdf

Since I also bought one of those Adafruit RTC stamps, I may yet give following this tutorial as written a try, but I thought that I could adapt the steps shown to the PCF8563. I tried doing the i2cdetect command and it found the PCF8563 at its address of 0x51. I did the command to add it as a new device and that seemed to go okay. There was an rtc0 device in /dev that I was able to write a time to and read from. I went through all the rest of the steps to set up a service to read from the rtc at bootup but whenever I power cycled the BeagleBone it would come up with a default date which was March 1, 2013.

I realized that something was writing time to the rtc, and went through a bunch of research to discover that there is a hwclock.sh script that is being called by several different boot levels in Debian that seems to be setting this default time to rtc0. The hwclock.sh script is at /etc/init.d/; the directories /etc/rcS.d/, /etc/rc0.d/, and /etc/rc6.d/ all seem to have the same script also but these are really just sim links to the one in /etc/init.d/. The other directories are used to define init scripts called at different kernel boot levels. This information is all swirling around inside the following comment thread:

https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=16218

I tried modifying this hwclock script as advised in the thread but didn't have any luck. I began to realize from reading the script and the messages in /var/log that the rtc0 device was some kind of default device and not the PCF8563 chip on my Waveshare cape after all. I tried doing modprobe commands as shown in the link above and in some other links I found and it seems like the rtc-pcf8563 "module" is something that I need and don't have and which should run when I add the chip as a new device on the I2C bus. I found some .ko files on my Debian system under /lib/modules/3.8.13-bone70/kernel/drivers/rtc but none of them are rtc-pcf8563.ko or rtc-ds1307.ko either for that matter.

A frequent hit that I keep getting while googling for the problems I am having installing this cape is the following site in what seems to be Hebrew or something. Without using Google Translate, I can tell that he's going through all the same steps that I did, using i2cdetect, adding it as a new device, and creating a service to load the system time from it a bootup. However, when he uses dmesg to check his log files after adding the device, he sees the "chip found" message that I'm not getting. I need to look at this site more carefully to understand what OS and distro he is using; if there's a chance he's using Debian it might give me a clue:

http://www.boonsanti.com/setting-a-real-time-clock-to-beaglebone-black-with-rtc-pcf8563/

Here's a listing for a Debian distribution that shows an rtc-pcf8563.ko file in the right place, but clearly this isn't my distribution. I need to find out the chances are that I can just find one of these .ko files and copy it onto my system (probably not great):

https://packages.debian.org/squeeze/armel/linux-image-2.6.32-5-versatile/filelist

Along the way as I did this research, I've learned that there is something called "fake-hwclock" which maintains current time in nonvolatile memory and reloads it during bootup, but I don't have that on my system. Here's a link with some info:

http://unix.stackexchange.com/questions/187261/automatically-update-hwclock-at-boot

I learned that Debian has a very nice editor called "nano" that has keyword color support and is easy to use (though not as easy as vi of course)

To edit system files, I had to change from the default login of user 'debian' to root, but when I tried "su root" it asked for a password. Various sites said that this distro had no password for root, but just hitting return on the password prompt wasn't working. I learned from the following page that I need to do "sudo su" to become root on this system:

http://www.element14.com/community/thread/32106/l/beagleboardorg-releases-debian-for-beaglebone-black?displayFullThread=true

I think that my system is using systemd instead of init. Here is what looks like nice info on systemd:

https://denibertovic.com/posts/setting-up-systemd-on-debian-in-10-minutes/

There's a book called "BeagleBone For Secret Agents" that had a google books excerpt that helped me better understand that rtc0 was not my cape, that it's an rtc inside the processor that doesn't retain time when powered off. It showed messages from a process named omap_rtc that was loading the default time and I was able to find those same messages on my system showing it setting the default clock to March 1, 2013. Here's the link to the google books excerpt:

https://books.google.com/books?id=i2OZBAAAQBAJ&pg=PT130&lpg=PT130&dq=omap_rtc+setting+system+time&source=bl&ots=9hLmjeWaPe&sig=j3ScuHRzYYN2Un2ljn_0gbsglgs&hl=en&sa=X&ved=0ahUKEwie9MXq5anKAhUIPT4KHZ6XB60Q6AEIJjAB#v=onepage&q=omap_rtc%20setting%20system%20time&f=false

Here's a blog by a guy who had a problem very similar to mine. He had an RTC chip that there was no module for in the distribution of Raspian that he had. He found drivers and compiled them and verified that the resulting module detected his chip. I need to carefully study this link to understand all of his steps and maybe try the same thing for my kernel and chip:

http://blog.remibergsma.com/2013/05/08/adding-a-hardware-clock-rtc-to-the-raspberry-pi/

When I google for drivers for the PCF8563, I usually get the following link, which interestingly is from a BeagleBone site so it seems that compiling this for BeagleBone is something that is done, although there don't seem to be any instructions or compiled module files at this link:

https://github.com/jeffegg/beaglebone/blob/master/drivers/rtc/rtc-pcf8563.c

Here's a guy interfacing a PCF8563 to a raspberry pi, and for some reason his kernel has the driver module already there. He does a modprobe command on rtc-pcf8563 and it works, so he goes merrily along with the rest of his installation steps.

http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/

Some links to stuff that I found which didn't directly help but I'm saving just in case:

Here's a hackaday article on the PCF8563 which goes into accessing its registers and stuff without showing any kind of finished code. Interesting, but I hope I never have to use it: http://hackaday.com/2009/06/26/parts-i2c-real-time-clock-calendar-pcf8563/

Here's a raspberry pi forum where some people are digging into the source code to find out why the rtc interface for the PCF8563 doesn't work for the PI2. Not useful to me but crazy smart: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=100132

Here's setup documentation for an expansion board for the pi that uses the PCF8563. It shows the "chip found" message that I should be seeing in my logs but am not. I wish my RTC cape had this kind of documentation: https://ludwig.im/en/projects/raspberry-pi/raspberry-pi-arpi600

It turns out that Waveshare makes another RTC board with a PCF8563 for a different kind of stamp computer development system. This information wasn't helpful however because the documentation for this other RTC board included no drivers compatible with the BeagleBone: http://www.waveshare.com/pcf8563-rtc-board.htm