Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspbian does not get the time from my RV3028 #9

Open
alphanumeric007 opened this issue Dec 18, 2019 · 22 comments
Open

Raspbian does not get the time from my RV3028 #9

alphanumeric007 opened this issue Dec 18, 2019 · 22 comments
Assignees

Comments

@alphanumeric007
Copy link

I ran sudo pip install rv3028 and sudo pip3 install rv3028.
Then ran the set-time.py file. And get-time.py shows the correct time.
Raspbian isn’t getting the correct time from the RTC though.
As a test I let Raspbian sync its time online, ran set-time.py and verified it with get-time.py.
Disconnected from the Internet and shut down.
On boot up the displayed time is the time it was shut down at, but get-time.py shows the correct time is stored in the RV3028?
I even did the manual install, but same deal. The RV3028 has the correct time stored but its not passed on to Raspbian?
git clone https://github.com/pimoroni/rv3028-python
cd rv3028-python
sudo ./install.sh
i2c is enabled and i2cdetect shows it at address 52.
Raspbian Buster with desktop on a Pi 3B+.

@Gadgetoid
Copy link
Member

This repository only concerns the Python library, and doesn't make any effort to set up the kernel driver to read time on boot/directly interface with the RTC.

Kernel support can be set up with the i2c-rtc overlay, by placing the following in /boot/config.txt:

dtoverlay=i2c-rtc,rv3028,backup-switchover-mode=1

@Gadgetoid
Copy link
Member

I've updated the README with a note about this because I can't find documentation for using this overlay anywhere else. I believe I was waiting for it to be merged upstream (raspberrypi/linux#2912) before documenting, so at least a reasonable subset of users have a chance of having the updated drivers installed.

@Gadgetoid
Copy link
Member

@sandyjmacdonald could this be a brief Learning Portal article for setting up the RTC? It appears my change requests/fixes have made it upstream now so it'd actually be worth us documenting.

@alphanumeric007 has a slightly more in-depth guide over on the forums - https://forums.pimoroni.com/t/rv3028-rtc-not-passing-time-to-raspbian/12479

@amahoneyLIT
Copy link

@Gadgetoid @alphanumeric007
Curious if backup-switchover-mode=1 works for ya'll. It was not setting register 0x37 as expected for me, so I used i2cset as a workaround: raspberrypi/linux#2912 (comment)

@alphanumeric007
Copy link
Author

backup-switchover-mode=1 didn't work for me, near as I can tell anyway.
https://forums.pimoroni.com/t/rv3028-not-keeping-correct-time/12836
Running the set-time.py file from the examples should set the correct backup mode for the batery. As long as you run it before doing the dtoverlay=i2c-rtc,rv3028 config.txt edit. I have my RV3028 working as a RTC in Buster, after a lot of head banging.

@Gadgetoid
Copy link
Member

This is strange! Were/are you running the latest version of Raspbian? I'm not sure when my backup-switchover-mode support patch finally made it into a distribution, but looking at the /boot/overlays/README file on my Raspbian Buster install suggests it's available in Buster at least.

@alphanumeric007
Copy link
Author

I was running the latest Buster with desktop, fully updated and upgraded. My RV3028 was working fine for days, over a month I believe. I hooked the tow I bough up shortly after I got them end of November. And one was left plugged into the Pi sitting on the shelf unpowered for a week or more.
As soon as I did the backup-switchover-mode to my dtoverlay entry everything went south.
https://forums.pimoroni.com/t/rv3028-rtc-not-passing-time-to-raspbian/12479/11
As near as I can tell that RV3028 has never worked correctly again. And the battery died. Might just be a coincidence though not 100% of the exact sequence of events after doing so many swaps of the RV3028's etc. I was starting to second guess myself after a while.
Phil, once you set that mode via the python set-time file, that mode sticks until told otherwise right?

@Gadgetoid
Copy link
Member

I'm pretty sure the backup switchover mode will stick on- yes. And will do so unless some other driver takes over and turns it off. It would also, probably I'm not actually totally sure, reset back to default if the IC lost all power (due to a flat battery).

@alphanumeric007
Copy link
Author

I'm going to try running i2cset -y 1 0x52 0x37 0x06 on my not working RV3028. I need to go get a new battery for it first. I was swapping my one good battery back and forth between the two breakouts I had, but still got the hwclock: ioctl(RTC_RD_TIME) to .dev/rtc0 to read time failed: invalid argument error when running hwclock -r on that one breakout. And the time would reset to Jan 2000 etc. The one I believe I had originally done the switchover mode edit in config.txt. As soon as I had issues I edited it back to just dtoverlay=i2c-rtc,rv3028 until I got one working RV3028.

@alphanumeric007
Copy link
Author

I meant to ask but forgot too, do they ship with the battery set to off, not used?
My current plan of action is to install the python stuff and then run set-time.py to turn the backup fuction on.
Then do all the edits etc to set it up as an actual RTC in Raspbian. All the stuff Adafruit says to do in their tutorial. and only use dtoverlay=i2c-rtc,rv3028
I'll be going through it all over again once my replacement RV3028 arrives sometime next week or so.

@amahoneyLIT
Copy link

I wasn't finding adding backup-switchover-mode=1 to actually do anything to the register

Right now I'm using dtoverlay=i2c-rtc,rv3028 and setting ic2set -y 1 0x52 0x37 0x06 but I'm finding occasionally (after unknown number of reboots) register 0x37 loses the backup switchover setting.

I wonder if it's the driver, or a nuance of the RTC. p.39 of the application manual (3.15.6 EEPROM BACKUP REGISTER), Symbol BSM states "To read/write from/to the EEPROM, the user has to disable the Backup Switchover function by setting the BSM field to 00 or 10 (see routine in EEPROM READ/WRITE CONDITIONS)". So I wonder if the driver does some EEPROM write which ends up resetting BSM to off.

Maybe I should just use this library, do a "date -s " on boot to sync with the RTC, and dont bother with the driver

@Gadgetoid
Copy link
Member

So I wonder if the driver does some EEPROM write which ends up resetting BSM to off.

I can't see any evidence of this happening in the rv3028 driver, but it does include functions for reading/writing the EEPROM.

Interestingly this would suggest a bug in rv3028_eeprom_write since it does not appear to reset backup-switchover-mode.

Backup Switchover Mode is enabled - depending on the config property - here:

https://github.com/raspberrypi/linux/blob/ab8652c03fa081b27de7e28a74c2536cb2aa3e5b/drivers/rtc/rtc-rv3028.c#L676-L689

@amahoneyLIT
Copy link

I just found the backup-switchover bit changed after walking away from my RPi for ~7 hours.

My /boot/config.txt contains dtoverlay=i2c-rtc,rv3028 without the backup-switchover-mode parameter

  • Friday evening - confirm 0x37 is set to 0x06 before shutdown
  • Monday ~920am - boot, confirm data was retained. Confirm 0x37 is still set to 0x06 (sudo i2cdump -f -y 1 0x52)
  • ... walk away from the pi
  • Monday ~430pm - Check 0x37 - it is now reset to 0x90 :(

@amahoneyLIT
Copy link

Backup Switchover Mode is enabled - depending on the config property - here:

https://github.com/raspberrypi/linux/blob/ab8652c03fa081b27de7e28a74c2536cb2aa3e5b/drivers/rtc/rtc-rv3028.c#L676-L689

I previously tried to trigger that "invalid backup switchover mode value\n" error message with no success, using very invalid values for the param

@Gadgetoid
Copy link
Member

@alphanumeric007 - It looks like we're making progress with this over here thanks to the input of @amahoneyLIT and others: raspberrypi/linux#2912 (comment)

Particularly the linked script will act as a handy quick fix to keep backup-switchover-mode set until we can get a fix into the kernel module.

@alphanumeric007
Copy link
Author

Run that linked script from terminal? Or as a py file?

@Gadgetoid
Copy link
Member

From the terminal by the looks of it- actually thought it was Python at first glance too. That's some crazy bash.

Will no doubt require the module to be unloaded, but once it's done I think the change is (semi) permenant.

@alphanumeric007
Copy link
Author

OK, thanks Phil. I was thinking from terminal, just not 100% sure. My two RV3028's are keeping good time as near as I can tell. They have been sitting idle for days at times. Neither Pi has been left on 24 hours though. On for part of most of the day but shut down and unplugged over night. I was turning the WIFI off before shutting down for a while there, so I know if they are working on boot up. Not sure if i did that last time though? I'll fire them up in a bit and try that script.

@alphanumeric007
Copy link
Author

I clip and pasted the whole thing into a terminal Window and got a module can't be removed error, followed by a bunch of device or resource busy messages. I'm going to remark its dtoverlay entry in config.txt and try again.

@alphanumeric007
Copy link
Author

With the dtoverlay remarked out
rmmod rtc_rv3028 gets me an error rtc_rv3028 module is not currently loaded message?
I guess i should be posting this in the other thread maybe?

@Gadgetoid
Copy link
Member

You can probably drop the rmmod line- and subsequent insmod- since the module wont be loaded if the dtoverlay isn't loading it. I'm guessing- in fact- that these should work even with the module loaded otherwise there wouldn't be much purpose to the remove/insert. I'm still playing catch up with this whole thing.

@alphanumeric007
Copy link
Author

I have no idea what any of it means if I'm honest. ;) I have that Pi turned off with the wifi disabled. I'll have a look see at it latter on today and see if its still working OK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants