-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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
|
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. |
@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 |
@Gadgetoid @alphanumeric007 |
backup-switchover-mode=1 didn't work for me, near as I can tell anyway. |
This is strange! Were/are you running the latest version of Raspbian? I'm not sure when my |
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. |
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). |
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. |
I meant to ask but forgot too, do they ship with the battery set to off, not used? |
I wasn't finding adding Right now I'm using 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 |
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 Backup Switchover Mode is enabled - depending on the config property - here: |
I just found the backup-switchover bit changed after walking away from my RPi for ~7 hours. My /boot/config.txt contains
|
I previously tried to trigger that "invalid backup switchover mode value\n" error message with no success, using very invalid values for the param |
@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. |
Run that linked script from terminal? Or as a py file? |
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. |
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. |
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. |
With the dtoverlay remarked out |
You can probably drop the |
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. |
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+.
The text was updated successfully, but these errors were encountered: