Has anyone managed to use the internal RTC on the Photon (using Vbat pin as backup power)?
My current application requires me to use a RTC and I would rather try using Photon’s RTC instead of using extra components.
Is there an official firmware library available?
I have queried this also. I have not yet received my Photon, so I can not test it. But what I have been told is:
If you put a battery or super cap on the Vbat (you have to charge it yourself since Vbat seems to not provide a charge), then, when the power (Vin, 3v3) drops, the RTC will continue to run. No library required.
@bing1106, the time library is built into the system firmware. If you can rely on internet/cloud connectivity, then you don’t need VBAT since you can sync the RTC with the cloud at regular intervals. If cloud connectivity is not reliable, as in more than a day, then using VBAT makes sense. You don’t need a library for that. Just hook up VBAT to a suitable supply like a CR2032 lithium battery for example. You can also use a supercap but it requires more circuitry to keep it charged. If you primary power supply (USB, Vin or 3.3V) is reliable, then you can just connect VBAT to the 3.3V line. 
Edit: it is recommended that VBAT be connected to the supply (3.3v) when not used. Not necessary but suggested. The RTC will still run if VBAT remains unconnected as long as 3.3v is powered
Edit 2: from the STM32F2xx manual:
If no external battery is used in the application, it is recommended to connect the VBAT pin to VDD with a 100 nF external decoupling ceramic capacitor in parallel.
Thanks for all your replies!
Currently, I have the Photon connected to both a 5V supply (it’s switch reg brings the Vcc to 3V3) as well as a CR2032 Li-ion battery on the Vbat pin. The goal is so that I can immediately inquire the current time whether I can connect to Spark cloud or not.
In my application, I need to be able to know the current time stamp as a device start-up condition. This means that even if cloud is available, I cannot afford to wait until the cloud is connected (best case I had was about 3 seconds from power-up and worse case it could be 10’s of seconds to connect to the Particle cloud).
With the Vbat connected to a battery, I still could not figure out how to use the RTC as a real RTC (like the DS1307). the time library does not allow me to set the RTC (using setTime()). Even with the battery supply on, once I power-cycle the Photon, the default time immediately went back to sometime in 1913.
Is there a way to use the RTC in Photon’s P0 as a real RTC?
@bing, that may be a side-effect of using the cloud connection. When the Core/Photon connects to the cloud, it will sync the time and I suspect that resets it even when the cloud is not available. Have you tried SYSTEM_MODE(MANUAL)? You have to manage your connection in this mode but it may not try and sync the time on bootup. You can also try SEMI_AUTOMATIC mode.
That could be true.
I am using the SEMI_AUTOMATIC mode right now where the Photon connects to the cloud or not based on D5 being high or low. This has worked out well for me in the past.
Before I started using the Cores and Photons, my set up was basically an Arduino Uno that uses a RTC device as I2C slave. So I could read the time stamp in my setup() right away when the device was powered up.
The goal now is to have the RTC run on its own (with Vbat) even without cloud. I am cheap and don’t want to use an extra RTC since the Photon has one…
@bing1106, this is a great test of the RTC! If I get the time, I’ll see what I can find in the firmware regarding the RTC initialization.
@bing1106, you are wanting to protect against power outages?
How long of power outages do you want to protect against, 30 seconds, 5 hours. etc.
The most power hungry part of the photon seems to be the WiFi. So how about:
Put a battery on the Vin. Detect when power goes off, and turn off the WiFi, and then maybe use sleep mode for several seconds/minutes. I am not sure if sleep mode will maintain the RTC tho. (I think it will).
@Jack, thanks for the suggestions.
I am not worried about power outages for the application. I am dealing with essentially two problems regarding time-telling:
This is quite analogous to the CR2032 Li-ion battery you might find in your desktop computer. On the motherboard, you would usually see a slot for that? This is almost the same use case where even if you unplug the computer power, the RTC on the motherboard still keeps track of time so next time you boot up the machine it would display the time (not accurate to the second but accurate enough). The desktop is not necessary connected to the internet.
But yes, I definitely agree about the Wi-Fi power consumption. In my P1 design I tied the Vbat for Wifi to 3V3 since I don’t want to waste battery life. But for the RTC, a CR2032 could possibly help keep the time keeper registers going for roughly 10 years, assuming a low self-discharge rate (which the CR2032 is quite good at).
That sounds great. So the only question remaining, is when main power comes back on (without cloud connection), will the RTC be read and used? I do not know that one. If you find out, let us all know.
I was hoping that could keep the internal RTC and cloud time separated. I think it is more reliable that way. The easiest way to put it would be: if there is cloud time available, use that and update the RTC every now and then. Until such option is available (still connecting or offline), use the RTC.
I believe, that when you boot up, the processor fetches the time from the cloud. After that, you have to request a sync time or just depend on the RTC.
@bing1106, when the device connects successfully, it updates the time: https://github.com/spark/firmware/blob/develop/system/src/system_cloud.cpp#L475
The RTC should continue running from then on with the 
synced time.
There’s an issue with the current firmware that will prevent you from doing tests unless you compile locally: https://github.com/spark/firmware/issues/440
Does that mean, 6 months later, it keeps getting the synced time, or, it got it 6 months earlier, and is running on its RTC?
Not clear what’s your question about.
Let me repeat myself again:
, it requests for a timestamp and updates the time valueOk, then, if we have not reset the processor for 6 months, it's time is based on what it requested from the cloud 6 months ago.
Yes, but you can sync the time as often as you'd like with Spark.syncTime()
http://docs.particle.io/photon/firmware/#spark-synctime
Synchronize the time with the Particle Cloud. This happens automatically when the device connects to the Cloud. However, if your device runs continuously for a long time, you may want to synchronize once per day or so.
Note that this function sends a request message to the Cloud and then returns. The time on the device will not be synchronized until some milliseconds later when the Cloud responds with the current time between calls to your loop.
You can also set the time to whatever you want with Time.setTime()
http://docs.particle.io/photon/firmware/#time-settime
// Set the time to 2014-10-11 13:37:42
Time.setTime(1413034662);
Is the syncTime() function actually writing time value to the RTC?
I've tried setTime() and set the Photon to an arbitrary time then powered the Photon off (but the CR2032 still supplies the Vbat). When I power the Photon back up without cloud connection (SEMI_AUTOMATIC) mode, the time I set was lost. It doesn't seem that the time set was remembered by the RTC.
Maybe I am accessing the RTC incorrectly?
Without cloud or power, the RTC should just keep running on it's own provided that Vbat is powered by a battery.
when you mentioned probably relates to what i mentioned above:
WICED library is resetting RTC each time it startup and has been fixed but not available using the 
compiler
@kennethlimcp is correct, try setting the time to something new and reading it before power-cycling the photon to check. Once the fix is rolled out it will persist through a power cycle 