Imho it is no changing circuit, as you’ve wrote the diode do a voltage drop (~0.7v) to be lower than the battery. And don’t allow flow from battery to vcc (direction).
Would have expected another diode like so:
Or:
Or:
Edit:
The drop over the diode is lower then 0.7, specially at very low currents:
This would mean the battery is trickle charging (less than a micro amp) when the board is powered… Which should be blocked by using a second diode.
Edit again:
Seems CR2032 is allowed a bit: Max Rev Charge: 1 microampere. Would we exceed it, when battery voltage is dropped already when it is half full?
This one has more interesting info on the topic:
Explaining why there is a diode and resistor as safety.
1 Like
Very interesting finding. I think R4’s design is missing another SOD323 in reverse.
As-is, when R4 is powered on, it seems a new CR2032 will very quickly discharge to about 3V. And after that point, it will get floating charged. When R4 isn’t powered on for a long time, the CR2032 drops way below 3V due to discharge. Then when R4 is powered on again, there is possibility of a fire disaster?
I’m kinda rusty on circuit design. Would like to have another opinion.
In the meantime, for existing R4 board owners, would it be safer simply going with a ML2032 instead of CR2032?
Looking at the voltage curve of the ML2032, the circuit looks more like a ML2032 trickle charger / backup circuit then a CR2032 (Conform European) backup circuit.
But it is up to the manufacturer to inform us, which components to use safely.
@sinovoip @simon Which type of battery can be used safely?
Edit:
According Panasonic (page 11):
This is a ML charging circuit:
So perhaps a ML1220 battery instead?
It is also a lot smaller 
1 Like
Agree. I believe the intention of the original ‘RTC circuit snippet’ of R4’s circuit designer meant to have a circuit for rechargeable button cell !
That’s actually better than my expectation. For all intent and purpose, I speculated that a single CR2032 could last the whole lifespan of R4 i.e. 10+ yrs. With rechargeable button cell, that’s even better IMHO.
I think BPI just have to check & confirm with their original circuit designer and revise the recommendation of usable button cells.
As an aside, I find the terminology interesting as per Panasonic pdf:
“Trickle charging” is when a cell is not under load. “Float charging” is when a cell is under load.
When 3.3.V is supplied from main power to R4, the button cell is discharge & charge at the same time. But it’s in the process of under load. Hence, it’s not “trickle charging” but “float charging”. So R4’s circuit is not harming the ML button cell.
Because of this, I’ve corrected my terminology in my previous post.
I hope we can get a 3rd and professional opinion.
UPDATE
After studied R4’s schematics a bit more, I believe the RTC will keep its time as long as the main DC power input is not interrupted. So personally for all my intents and purposes, to keep the clock during warm boots, I’m fine without a RTC battery.
My concern about R4’s RTC battery charging circuit is that VCC_RTC is tapped off AFTER resistor R75. I believe the correct way perhaps is to tap off before R75. The resistor should be for the purpose of limiting charging current. I’m afraid that as-is in V1.1 unknown current will be charging the button cell and damages it prematurely anyway (?)
1 Like
If i understand it right we should add a diode in + line when using cr2032 (D3 in second picture),right (to prevent current flow from 3v3 to battery+)? This seem to be easiest way,but imho this will drop voltage from battery to 2.3V
See the graph about the diode forward characteristics I posted earlier, the drop is about 0.2V at these low currents. Should be ok. But easier is to use a ML2032 in the holder you ordered, it is the same size as the CR2032.
But anyway, the manufacturer needs to state which battery to use, to keep C E.
1 Like
I also ordered ml2032,but they take 2months of shipment.the holder/cable should arrive next week so i need a solution to use what i have…and if i can use simple 1n4148 with cr2032 the i can test earlier
And sorry about my fixed 0.7v voltage drop by diode…seems this is burned in my mind 
The clock is powered by the 3.3V from the board, so why do you need a battery for testing? One would think…
But when the i2c communication is started, current draw of the RTC is almost 1mA, a lot more then without i2c.
The voltage drop over the 2k2 resitor would then be 2V, down to 1.3V. But we need at least 1.8V for i2c communication.
This indeed does not make much sense, and we can only read the clock when there is a battery installed?
1 Like
Just use without diode for testing, I do not think you will immedeately burn your house down. You would be present anyway. But just to be on the safe side, remove the battery after testing, as it is not following the battery manufacturer specifications.
@riskable also seems to have survived the experience. Appropriate nickname here 
1 Like
In my previous tests i get an error from rtc when it is probed…but yes,maybe i only need to save the clock first and then do only software reboots for testing if the clock survives this…but after poweroff the clock will be reset of course. I always poweroff the boards when not working on them. But problem is on poweron that battery may get hot because it is charged…adding the diode may prevent this and battery damage
I think the voltage drop too low behind R75, if there is no battery…
1 Like
Hi, thanks for sharing your wisdom, can you help me with this question, can these RTC batteries for Raspberry Pi 5 be placed on the BPI-R4? The 2-pin JST connector is a bit longer, but I think the pitch connector is still 1.25mm.
Or is it better to buy the one you recommend?
- ML1220 (17mAh) Amazon - Aliexpress - eBay
It is not up to me to recommend the type of batteries, but up to the manufacturer.
I was only concerned about a possibly dangerous situation, using non-chargable batteries on a charger.
1 Like
For this reason?
You can use the ML2032 in any device which accepts CR2032, but you CAN’T use the CR2032 in devices which accept the ML2032, because the CR2032, being non-rechargeable, might EXPLODE when trying to be recharged.
Source:
at least i tried if rtc will survive reboot without battery…and it does
root@bpi-r4-v11:~
# dmesg | grep rtc
[ 1.479923] rtc-pcf8563 2-0051: low voltage detected, date/time is not relia.
[ 1.487390] rtc-pcf8563 2-0051: registered as rtc0
[ 1.493378] rtc-pcf8563 2-0051: low voltage detected, date/time is not relia.
[ 1.500771] rtc-pcf8563 2-0051: hctosys: unable to read the hardware clock
root@bpi-r4-v11:~
# date -s "2024-04-27 09:55 CEST"
Sat Apr 27 07:55:00 UTC 2024
root@bpi-r4-v11:~
# hwclock -w
root@bpi-r4-v11:~
# hwclock -r
2024-04-27 07:56:23.979830+00:00
root@bpi-r4-v11:~
# reboot
...
root@bpi-r4-v11:~
# dmesg | grep rtc
[ 1.480067] rtc-pcf8563 2-0051: registered as rtc0
[ 1.486061] rtc-pcf8563 2-0051: setting system clock to 2024-04-27T07:56:53 )
root@bpi-r4-v11:~
# date
Sat Apr 27 08:00:46 UTC 2024
root@bpi-r4-v11:~
oh, and it looks like it survives ~2h with full power loss (only uart connected but this has no vcc).
2 Likes
As expected from my rusty circuit analysis.
Thanks for verifying for us w/o R4 yet
The 47uF capacitor at VCC_RTC is the hero (thanks to BPI for putting it there). From my back of the envelope calculation, enough electricity to power the RTC for 4-5 hours if not longer when main DC power is off.
To R4 owners:
for all intents and purposes, you don’t need a RTC battery like I said before.
1 Like
had it off for ~7h…still working…
[ 1.486064] rtc-pcf8563 2-0051: setting system clock to 2024-04-27T11:22:02 UTC (1714216922)
[ 1.486000] rtc-pcf8563 2-0051: setting system clock to 2024-04-27T18:42:44 UTC (1714243364)
today my cables and cr2032 holders arrived
1 Like
I helped an OpenWrt user to enable the RTC in snapshot for BPI R4. And enabled the RTC for myself as a byproduct. So took the chance to test how long the RTC can survive offline without a battery.
My BPI R4 is 4 hours. RTC keeps the time perfectly fine.
At 4.5 hours, low voltage detected.
@frank-w I wonder how yours lasted so loooooong…
Maybe you have more client-devices which taking current…maybe there is a current backflow over serial-uart…i saw the power led is dimmed when uart is connected…possibly i had not cut off all connections (also using a switchable dc-connector).