I finally got a reply from Pimoroni Tech support via e-mail. I can get a replacement RTC if one is bad and I think I’m going to take them up on the offer.
I just swapped in the one I suspected was bad, and the one I’m pretty sure had the dead battery in it. I remarked out the dtoverlay entry in config.txt and rebooted.
Then ran set time, reinstated the dtoverlay entry, and rebooted.
Running sudo hwclock -r gets me that same error message.
hwclock: ioctl(RTC_RD_TIME) to .dev/rtc0 to read time failed: invalid argument
I just can’t trust that module to be reliable.
I ran in to similar problems with my rv3028 module not keeping time if backup-switchover-mode=1 is specified in /boot/config.txt.
It turns out there are two backup switching modes in the device: LSM (level switching mode) and DSM (direct switching mode). The set-time.py and get-time.py scripts set LSM, but the config.txt entry is selecting DSM.
It would seem that DSM doesn’t work for some reason (for my module, anyway) - I don’t really understand how LSM is supposed to work as the rv3028 manual talks about V-backup being above a 2v switching threshold, and our battery is only 1.55v. Still, as LSM seems to work, I can live with that.
The device tree documentation says you can set backup-switchover-mode to 0 or 1, but the kernel driver code and the device allow values 0 to 3, with 3 being LSM and 1 being DSM.
So, I guess setting backup-switchover-mode=3 in config.txt would work, but if you’ve used set-time.py to set the time anyway, as per the instructions, then there is no need to specify backup-switchover-mode at all as the value is already set. to LSM.
So, my question is: Why did the original python code select LSM and then the more recent update effectively tell you to select DSM via config.txt? Is that a bug? Also, why are only values 0 and 1 for backup-switchover-mode documented?
I’ve only ever been adding
dtoverlay=i2c-rtc,rv3028
to my config.txt.
I do run set-time get-time just before doing it. I also disable the fake hwclock.