Raspberry Pi does not recognise DS3231 RTC chip module during OS startup

carriba · Sep 30th 2016

I have a DSR3231 RTC chip module hooked up on the GPIO pins of a Raspberry Pi 2 computer, which works fine on other RPi devices using Raspbian Jessie or UbuntuMATE OS.

For my OMV 3.0.24 (Erasmus) installation on another RPi 2 device, I am following exactly steps described with the article "Supporting DS3231 RTC source & synchronise with network time" .

To start with, I've added in the "/boot/config.txt" configuration file the line

dtoverlay=i2c-rtc,ds3231

However, once the box gets powered up, I do not seem to find any entry in the startup log that points out that the RCT chip is properly being recognised. When firing the command "dmesg", there's simply no log entry that confirms that the RTC chip has been recognised either

The same is the case, when firing the command "ls -l /dev/rtc0". I'm getting an output of "file not found".

Does the kernel compiled for OMV 3.x supports the notion of overlays for RPi add-on modules or is there anything I might have missed?

David B · Sep 30th 2016

You might find this post helpful. It helped me when my RTC module was not working.

carriba · Oct 3rd 2016

This pointer may be useful for the classical approach when using Raspbian Wheezy OS, where you need to use the i2ctools as described in the "Adding a Real Time Clock to your Raspberry Pi" tutorial.

However, with the kernel release 3.18 onwards of Raspbian you can use the the concept of "Device Tree Overlays", which ought to recognise the RTC chip during boot up - no need to activate the I2C bus at all!

However, I do not get there yet to recognise the add-on module

Once the module is recognised during boot up, I can move forward and setup the RTC on the OS level. When testing OMV 3.0.24 (Erasmus) installation, it is using the systemd as the "init" system, thus making an ideal candiate to configure the RTC on the OS level according to the article "Supporting DS3231 RTC source & synchronise with network time".

David B · Oct 4th 2016

I'm afraid I cannot help you with that. I have only ever used OMV3 in a virtual machine, and since my experiences with it have not been positive, I am sticking with OMV2 on my RPi right now. The problems that I have experienced with OMV3 have do not have to do with OMV3 itself, but rather, with plugins that I use on my live system that have not functioned properly with OMV3 in my testing VM.

carriba · Oct 4th 2016

Yes, OMV 2 is working fine for me, too, and everything is under control.

Just with OMV 3, there quite many bricks to move around. I'll give another try this week to figure it out...

jata1 · Oct 11th 2016

I have RTC clock working fine on OMV 3. See following thread for a summary of steps.

OMV 3.0 - clean install on RPi with a RTC module

The key steps are:

1. install OMV 3
2. enable SPI and I2C through advance settings of raspi-config (use apt-get to install raspi-config)
3. config OMV to use NTP server (OMV GUI date & time screen)
4. add "dtoverlay=i2c-rtc,ds3231" to /boot/config.txt.
5. Edit /etc/init.d/hwclock.sh, by comment out following lines (add # at start of each line)

#if [ -d /run/udev ] [ -d /dev/.udev ]; then
# return 0
#fi

6. Disable fake-hwclock, and enable hwclock.sh using following commands

sudo apt-get remove fake-hwclock
sudo rm /etc/cron.hourly/fake-hwclock
sudo update-rc.d -f fake-hwclock remove
sudo rm /etc/init.d/fake-hwclock
sudo update-rc.d hwclock.sh enable

to test it is working, reboot and run the following command

sudo hwclock -r

This command should return correct time from the hwclock.

hope this helps you.

ryecoaaron · Oct 11th 2016

If you have a hwclock, you probably want to remove some of the lines in /etc/rc.local as well.

jata1 · Oct 11th 2016

Thanks.

Although my RTC is working fine, i do see a system time change right at the end of the pi boot sequence - see log entries below.

Oct 11 08:19:16 pi-omv systemd[1]: Started Beep after system start.
Oct 11 08:19:16 pi-omv systemd[1]: Startup finished in 2.190s (kernel) + 18.766s (userspace) = 20.956s.
Oct 11 08:20:06 pi-omv systemd[1]: Time has been changed
Oct 11 08:20:06 pi-omv collectd[1344]: rrdcached plugin: rrdc_update (/var/lib/rrdcached/db/localhost/load/load.rrd, [1476170406:1.840000:0.530000:0.180000], 1) failed with status -1.

when this happens, it causes a bit of an issue with rrdcached (see last line above - there are a few pages of these) but this sorts itself out and the graphs are fine in the performance statistics page.

I have tried commenting out the following lines in rc.local but it doesn't seem to make any difference.

#ntpdate-debian -b time.nist.gov
#fake-hwclock save force
#systemctl start nap

Do you have any ideas what could be causing the time change at the end of the boot sequence? i'd like to stop this from happening.

ryecoaaron · Oct 11th 2016

Probably ntp starting?

jata1 · Oct 11th 2016

Not sure if it's ntp starting. I thought that it could be ntp so I commented out the ntp line in rc.local - #systemctl start ntp

commenting out the lines in rc.local didn't make any difference.

how can I check if it is ntp being started?

not sure how/why the time is out by ~50secs as the hwclock is working and based on ntp. When it reboots, I'd expect ntp and hwclock to be in sync...

ryecoaaron · Oct 11th 2016

ntp start at boot is determined by the Use NTP Server in the Date & Time tab. It is enabled by default on the RPi image.

No idea why time is wrong.

jata1 · Oct 11th 2016

OK. Thanks Aaron. Not sure what else I can do to resolve this.

Is there any way of getting more detailed information on what is triggering the systemd event - systemd[1]: Time has been changed

The time change happens immediately after the message confirming startup finished - systemd[1]: Startup finished in 2.190s (kernel) + 18.766s (userspace) = 20.956s.

I'm assuming that rc.local has run at this point. Is this correct?

Do you know where/how the startup finished event comes from?

Is it possible for me to add some debug messages that get inserted into syslog to try to find the source?

ryecoaaron · Oct 11th 2016

I think you need to find out why the system clock is not being sync'd to the hardware clock at shutdown. This is probably why there is a large change at startup.

jata1 · Oct 11th 2016

that's the strange thing. hwclock is in sync at shutdown as far as I can tell. If I run hwclock -r it is sync'd with system clock. then reboot and I have the issue. Do you think something is changing the hwclock during shutdown?

I'm going to buy another RTC module to see if this fixes the issue.

It's a small issue but really annoying me. OCD!

OMV 3 is working well on my the RPi though. No major problems but I have found a few minor issues/errors - e.g. 'report' page in diagnostics section of GUI fails to load.

ryecoaaron · Oct 11th 2016

I was having good luck with the latest image without the RTC. Try that.

Is there an error with the report page? I don't have my RPi turned on.

jata1 · Oct 11th 2016

Yep. error box/message when clicking on report page - page doesn't load. I'm at work so I don't have access to my RPi either.

I like having the RTC as I use the performance monitoring stuff/charts - cpu and network activity. I think you need RTC for this as chart data / rrdcached gets screwed up with date/time being set as 1970 during startup.

I'll see if anyone else in the community has an RTC working without the issue I have on a RPi running OMV 3.

I'm also going to get another RTC to eliminate an issue with the device/hardware.

thanks for the help and

jata1 · Oct 11th 2016

Aaron - one last thing...

what parts of rc.local should I comment out? I have commented it all out. Doesn't seem to make any difference but good to know what I should remove/keep.

ntpdate-debian -b time.nist.gov
fake-hwclock save force
systemctl start ntp

I am thinking that the first 2 lines are not needed but maybe the last one is important as it is linked to using NTP service in date/time settings for OMV.

ryecoaaron · Oct 11th 2016

Quote from jata1

I think you need RTC for this as chart data / rrdcached gets screwed up with date/time being set as 1970 during startup.

I thought this should have been fixed since fakeclock was writing the correct time to the file to be restored at startup. It might be a little off (last shutdown time) but it shouldn't be 1970.

Quote from jata1

what parts of rc.local should I comment out?

All of it should be able to be comment. The ntp start command is only there because the matching ntp stop command is in the same file.

jata1 · Oct 11th 2016

I think what you are saying is that you don't really need a RTC in OMV 3. So all this time me playing with RPi and RTC is not needed on on OMV 3 for my use case. That's funny!

So, how do i remove the hwclock and go back to fake? I guess reverse some of the stuff i did to get hwclock working.

Is following OK?

sudo apt-get install fake-hwclock
sudo update-rc.d -f fake-hwclock enable
sudo update-rc.d hwclock.sh remove

but i don't know how to reverse these as it looks like I have deleted 2 directories.

sudo rm /etc/cron.hourly/fake-hwclock
sudo rm /etc/init.d/fake-hwclock

ryecoaaron · Oct 11th 2016

Quote from jata1

I think what you are saying is that you don't really need a RTC in OMV 3. So all this time me playing with RPi and RTC is not needed on on OMV 3 for my use case. That's funny!

Not quite. I am saying I haven't needed it but I have monitoring turned off. In my opinion, it is an RPi and shouldn't have important things on it and not need graphs. But that is me.

If you re-install fake-hwclock, it should enable it automatically but your commands won't hurt. I think it will create the cron and init files too. I haven't tried it though.

Raspberry Pi does not recognise DS3231 RTC chip module during OS startup

Participate now!

Tags