I am looking through the core firmware code and I see a reference to an onboard RTC but I don’t see any public methods for accessing or using it. Is there an on-board RTC and can it be accessed via an arduino “time”-like library?
@peekay123 , if you just need to keep track of time relative to when the core last rebooted, the time functions like
millis() will work. If you need to be synced with actual UTC time, you could try something like described here or here to grab the value, then use
millis() as an offset against that.
jgoggins, I contributed to the UDP NTP call code and have it working What I am asking is if there is real time clock hardware built into the STM32. I will have to look at the STM32 specs. Thanks!
Oh, funny. This community is so chalk full of active and helpful people like yourself, sometimes I forget to see who wrote what before I reply, Looking forward to hearing what you find from digging into the STM32 specs!
Quick summary as I understand it: There is an RTC on STM32 but no software to access it yet from . The battery backup Vin pin for the RTC is tied to normal core power in the current PC board, so making a battery-backed-up RTC will be hard.
Well, its a start! Can anyone on the Spark team tell me if the RTC is clocked internally or with an external crystal and is access to the RTC on the development timeline?
There is an RTC on the STM32 and usage of it is exposed via the documented time functions.
I would be very happy to be wrong, but the documented time functions deal with elapsed time, not real-time. I look forward to whatever you guys can do in this area!
I believe the core is externally clocked ( @mohit please correct me if I’m wrong!). The red circle on this photo is over the flash chip, but I think the component that says “8.00 Mhz” on the bottom-right is a clock crystal:
Also, probably worth bringing up this thread again, some great discussion about clocks here:
Small correction: The 8Mhz is the system clock for the STM32. while the smaller one next to it is the RTC crystal (32Khz).
Since the VBAT is directly connected to 3v3, the RTC wil restart on power up. The only work around is to use
millis() to sync up with UTC. It will not make sense to add a RTC function without the ability to connect VBAT to a battery source.
What would have to be done to get the RTC working from a small coin cell battery? Would the board need to be revised on future production runs to allow a Vbat connection to the RTC so it keeps time when the spark is off?
Or is there a low power feature that we might be able to use to Shut Down the Spark Core when needed and yet still only feed the RTC?
Just thinking, sine the RTC is a valuable feature that normally requires a separate RTC breakout which cost dam near as much as the Spark Core.
You can solder in a wire on pin 1 of the STM32 and power it via a coin cell (add a diode in series) - this is untested but might work.
The second option seems doable by putting the Core into deep sleep and letting only the RTC run.
Soldering a wire to Pin 1 is a easy thing to do. I wonder what the power consumption would be going this route?
Putting the Spark Core into deep sleep is another good option. I wonder what the power consumption is for this option and if it would be the same as wiring a coin cell to Pin 1?
It seems like if your feeding the Spark Core with a voltage above 3.3v that there is a dc to dc regulator wasting power to regulate the input to a 3.3v the Spark Core needs to run. If that is the case the Coin Cell wired to Pin 1 would have the lowest power consumption of the 2 options.
Looking at the Core firmware, the RTC is enabled and configured by a call in MAIN.C. The only other RTC code I find is for setting the RTC registers, handling the RTC interrupts and some rudimentary RTC housekeeping functions. The function RTC_SetAlarm() is called from sleep() to wake up the core up after the predefined time. Otherwise, the RTC_IRQHandler() in stm342_it.cpp has commented-out code to measure a day going by but nothing else. So, code wise, the RTC is obviously a work in progress.
You all might want to read this thread as well: