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

  • 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?

  • 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".

  • 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.

  • 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.

  • 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.

  • 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...

  • 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.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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?

  • 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.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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.

  • 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.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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

  • 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.

  • 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.

    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.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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

  • 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.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!