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

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

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

      The post was edited 3 times, last by carriba ().

    • 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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.1
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.1
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.1
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      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.
    • jata1 wrote:

      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.

      jata1 wrote:

      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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.1
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      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
    • jata1 wrote:

      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 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.1
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!