Uhh... ignore what I said previously about not having the 32KHz XO. Apparently there's a 32KHz crystal onboard hooked up to the RTC_XTAL. (This is why I should never rely on memory with hardware specs :/ )
That said... Yes, I believe that VSTBY should keep the RTC_XTAL running regardless of the rest of the processor. I'd recommend waiting for either Matt or Paul to jump in on this before making any permanent decisions, but it should work. If you've got a board in front of you, you can always try it and see
Lol - Ok thanks. The problem with "try it and see" is that only means it works on that one board that you have at that point in time - not necessarily that it has been designed to work that way on all modules. I'd rather hear that that's the way it was designed to work .... and then try it!!
But thanks for your help, I was trying a few things over the weekend and they seemed to be working ok - the biggest problem I had was working out what the right Time Zone format string to use for the Uk!! ("GMT0BST-1,M3.2.0/01:00:00,M11.1.0/02:00:00" seemed to work but the daylight saving switch over days aren't right - I think we switch always on 3rd Sunday in March and October so I think this would be "GMT0BST-1,M3.3.0/01:00:00,M10.3.0/02:00:00" - but all I wanted to get was a time 5 hours different to Eastern Standard US time.
For those curious, the hardware is attached in the expected manner. The 32.768kHz crystal is Y3 populated on the board with direct connections to the RTC XTAL and EXTAL pins. VSTBY is standby power, connected directly to the VSTBY_RTC pin with a nearby .1uF cap to ground, and a 10ohm resistor and diode in series to 3.3V power for the board. This means you should be able to just hook up a supercap from VSTBY to GND, program the device to activate the RTC and have it work, no other hardware necessary. The general board power will feed the supercap when it's powered, and the diode will prevent the rest of the board from draining your supercap.
This won't work on a MOD-DEV-70 however as the VSTBY pin is connected to power directly. If you have some other board to try it on, it should work fine though.
Thanks - that's very useful info ... it's just a pity it's not part of the Netburner documentation ...
These modules are a great platform to build on (both hardware and software), but I think they could do with a bit more documentation to guide hardware designers - especially for hardware designers using Netburner modules for the first time. Just exactly the sort of thing that you've put in one sentence in your post. Simple - but vital information.
Hmmm ... Just something to watch out for. The 17uA needed to keep the RTC working with power off is quite high. A super capacitor is not going to keep the RTC working for long!
According to the Freescale manual, V Standby has to be kept above 1.6v and the max current is 17uA. I think with a 17uA current load, my 0.33F supercapacitor will discharge to 1.6v in about 12 hours.
So ok for development and testing maybe, but not so good for a "real" application where a device might be powered off at least for over a weekend, and maybe a factory 2 week shutdown.
So in practical terms a 3v battery is really going to be required - probably of 100 mA.hours or more to get toward a year of backup. Either non-rechargeable coin cell and just change annually, or re-chargeable - BUT watch out for using the correct charging circuit - don't constantly trickle charge a 3v rechargeable!
If i had to guess, the RTC on the processor is designed for keeping time when the device is powered up and simplifying overall system design. Given that the processor is designed as a network connected device, it would be fair to assume that it can query for a network time on boot, and simply "cache" the time during operation. I guess this is a good time to plug our NTP Server! You could simply ping a NTP server once and hour or so to keep synced, and if the RTC isn't valid on boot, refresh. If I recall, we have code for setting the local RTC from network time.
Hi Dan - yes good suggestion - for the RTC - BUT not all embedded devices have an actual internet connection! They might use the ethernet for local inter device comms or data collection. This is what my application is. The module will be in instruments in machines in factories (like metal foundry for engine casting for example). There is rarely an internet connection available...
Besides it's not so helpful for the onboard static RAM - no amount of NTC refreshing will restore that once the battery or capacitor is gone!!
But I take your point. Do you agree that the super capacitor (eg as on the MOD70) is only likely to maintain the RTC for a few hours, 10s of hours at the most?
Without rerunning the math myself, I'd agree that you're in the ballpark. I seem to recall us discussing this one internally and the largest supercap arrangement that wasn't comical would be a few days at best.
On the note about internet comms, I agree with what you have to say. I was simply pointing out what I thought Freescale had in mind when deciding that 17uA is an acceptable battery backed current. That said, it really is becoming feasible to have a standalone timeserver in a production environment. While you can't assume one to be present when designing your product, they make it simple to manage time across a production network, and as the price keeps falling, they're becoming more commonplace. All you need is power and a view of the sky for them to work.
Fair points Dan. I'll bear that in mind. What would be really good would be a small industrial (din rail mounted and 24v powered) Ethernet router with DHCP, DNS Server (so devices names could be allocated rather than having to browse to IPs), and with time server included.
This would be great for small local machine cells that the customers IT people won't allow to connect to their wider network or internet (I say router so it has a WAN port for those few occasions when you can get an internet connection. Finding something cheap that includes a DNS server is my problem.
