I’ve being having the odd problem with the RTC on my custom Artemis boards freezing occasionally. It’s only specific to some hardware, or perhaps high humidity, and is horribly intermittent -ie. on one board, after resoldering things the RTC works fine, but a few hours later it freezes again. I’ve not had this issue with any Sparkfun boards. I don’t know if I’m using the same crystal but I matched the 15pF capacitors from the Sparkfun boards as it all seemed pretty generic and transferrable.
I’m using this crystal (apparently pretty bog standard):
In my travels I came across some theory on how crystals and loading capacitors work, and it seems like the 2x 15pF are almost certainly too high for the nominal 12.5pF in my crystal datasheet, right on the edge of “will just work, in most cases”. They probably should be 6pF, although I didn’t finish figuring that out because…
Page 525 of the Apollo3 datasheet (exerpt below) actually says that these capacitors aren’t necessary! It has compensation stuff internally. Lower part count, cool. I’ve just removed the loading capacitors on a few custom boards and the RTC still works. The datasheet then goes on to sort of contradict itself by talking about minimising leakage in load capacitors.
I’d be interested to hear from Sparkfun what crystal is used on the stock boards and any rationale behind loading cap selection. I’ll be removing loading resistors off most of my custom boards and seeing how they go.
PS: Anyone who got this far might be interested to learn the datasheet also references (on page 526) an “Oscillator Fail (OF) flag” which can be used to detect failure of the external crystal.
12.1.3 High Precision XT Oscillator (XT)
The high accuracy XT Oscillator is tuned to an external 32.768 kHz crystal, and has a nominal frequency of32.768 kHz. It is used when frequency accuracy is critically important. Because a crystal oscillator uses a significant amount of power, the XT is only enabled when an internal module is using it. Digital calibration logic is included. The output of the XT oscillator may be digitally calibrated to ±1 ppm (part per million).
It should be noted that the XT oscillator is also optional if the requirements of the design can tolerate the internal LFRC/HFRC oscillator specifications. It should also be noted that external capacitors are not required to tune an internal divided clock of the crystal input to achieve a precise scaling of 32.768kHz. This is handled within the Apollo3 Blue MCU.
NOTE: The XTAL is highly sensitive to external leakage on the XI pin. Therefore it is recommended to minimize the components on XI and to use extremely low leakage load capacitors.
Good hunting and datasheet reading. I had seen the internal calibration of the 32kHz XT oscillator referenced a few times and was always weary. Similarly, at the time I did not find anything helpful as a cal example in the Ambiq SDK. So to answer your first question as to why there are caps there, we were following practices from ages before.
Cap part #: 06035A150JATN (15pF 50V 5% C0G)
Xtal part #: Geyer 12.87150 (32kHz 12.5pF CL)
Let us know if you get the calibration routine working. It would be good to know if the caps can be left off if needed.
Thanks for the quick reply. So the Sparkfun crystal and caps are the same specs as the ones I’ve been using and having occasional troubles with (ie. a good chance the occasional RTC troubles are a function of my custom board, probably one involving slight extra capacitance, perhaps from putting the crystal and caps on the opposite side of the PCB to the Artemis, although the Nano board does this too).
For the record, below are some good references on crystal load capacitors. These agree perfectly with the Sparkfun design of the crystal and caps, albeit hung off the assumption of 5pF of stray capacitance. Perhaps this assumption is less valid considering the path through the module to the Apollo3 chip, and as a result of the Apollo3 internals.
Aha! p778 “Table 1147: Clocks/Oscillators” gives “Allowed external XI/XO pin capacitance per pin” as 7pF max. Also 3.4pF per pin is provided internally. Still not explicit whether the 12.5pF Cl wanted by the crystal is provided by the Apollo3 alone. It seems fairly certain though that 15pF external loading caps is much too high.
A couple of my custom boards, and an Artemis Nano all still work immediately with with crystal caps removed, or at least flipped 90deg so one of the pads is disconnected, consistent with the “external capacitors are not required” from the datasheet. Ie. NO CODE CHANGES NEEDED.
As such, I would guess the digital calibration routine (datasheet section 12.1.3.1 XT Oscillator Digital Calibration) is optional - icing on the cake. I will look at that if I get a chance, seems simple enough and a worthy thing to do.
yes, the caps are too high. I have a bunch of fielded devices that do a timesync every day… they are about 1.5 seconds off per day, I forget which way ;/ but it’s pretty consistent. You can use the ambique clock tuning code in the sdk to tune for that, or just put the correct caps on you’re board there was a post a while ago abt this, people thought it was tempurature related at first but the time shift I see is very consistent
also- stephenf, you’re code will still run even if you unsolder the 32k… if the pll doesen’t lock to that then it just runs in free run… but will probs have considerable drift/innacuracy…
Thanks for taking the time to comment, great to have another perspective (and some reassurance!).
I knew the code would still run without the external crystal (ie. it uses the much faster internal crystal) but I was surprised to think the RTC would still work with the crystal missing. So I desoldered the crystal on an Artemis Nano and ran the RTC Example1. As expected, the code still runs and millis() is accurate. The RTC still works, but apparently only at ~30% speed (printing every second according to millis, the RTC time only advances about 0.3sec). That might help someone debug a soldering error if their RTC is running really slowly.
I’ve still been having crystal issues on my custom boards. No dabbling with software calibration yet.
It seems that removing the capacitors altogether makes for an excessively low capacitance (the clock runs fast, gaining quite a lot), at least without using the software calibration, which possibly adds capacitance, or maybe just adds a correction factor.
I’m doing more tests - meanwhile maybe don’t remove caps from your design on my account just yet…
Meanwhile, 4x Artemis Nanos which have been running for 3+ months in temperatures 5-30degC have generally gained 10sec/month, which seems pretty reasonable and reassuring.
If you read further back in the thread, there is explanation of why the stock 15pF capacitors should be the theoretically correct value for a crystal with Cl of 12.5pF.
I must eat some humble pie and remember that theory that if something doesn’t work, it’s probably your own fault rather than the chip manufacturer, the firmware or the reference design…
It would appear that my issues with the crystal freezing are due to excess flux and soldering residue under and around the crystal (and maybe the Artemis module). This explains why 5 of my custom boards will not freeze no matter what I throw at them, and the other 5 intermittently freeze from various obscure changes in temperature, pressure and humidity. Leaving them outside overnight is the best test, apparently. A few would only freeze in this way, doing just fine in the fridge, and in my office long term.
I think the stock capacitor values (15pF) are pretty good, ie. for my custom boards:
With 15pF capacitors, the clock gains something like 1 second per day (12ppm, a fairly acceptable accuracy, I gather)
With capacitor values of 7.5pF (2x 15pf capacitors in series on each side of the crystal) - the clock gains about 6sec per day
With no crystal capacitors - the clock gains about 30sec per day
For 4x Artemis Nano modules, over 3 months of variable temperature (outside in white PVC housings), they gained 30, 70 and 80 seconds, and one lost 30sec.
It’s still unclear what’s inside the Apollo3 in terms of capacitance, but the stock values seem pretty good, and if you need better accuracy than that, software calibration is probably the best way to do it. If I get a chance though, I might try a slightly higher value at some point.
A brief follow up some weeks later - cleaning flux off the crystal, the crystal capacitors, and in one case, the underside of the Artemis module seem to have fixed my issues. In the next version of the board I’m going to put the crystal/caps on the same side and make closeness to the Artemis module a higher priority (they are currently about 10mm away on the opposite side).
For what it is worth, I have been using the digital calibration mechanism and it works fine. The only thing that makes it non-trivial is that you need a frequency counter connected to one of the CLKOUT pin choices (Apollo3 pad 0 or pad 7) so you can find out what your actual XTAL frequency is.
To clear up a misconception, the calibration mechanism does not actually calibrate the XTAL! What it does is to calibrate the number of divided-down XTAL clock ticks that will be observed over any 64 second interval. Simplistically, the calibration hardware inserts or removes individual XTAL clock events over that 64 second span based on your calibration constant. If your XTAL is too fast, the system will skip an XTAL clock once in a while. If the XTAL is too slow, the system will insert a fake XTAL clock once in a while. Over the 64 second interval, the total number of ticks will be much closer to matching what would have come from a calibrated source over that same interval. But since ticks are being artificially inserted or removed, there will be some extra frequency jitter in shorter intervals!
The effects of this mechanism can clearly be seen by putting a frequency counter on a calibrated clock output. You will see the frequency counter run fast for a while, then slow, then fast, then slow, without ever landing on the ‘calibrated’ frequency. But over a 64 second span, the calibration mechanism ensures that the average CLKOUT frequency would match the desired calibrated frequency. This form of calibration mechanism is simple and cheap (silicon-wise) and will work nicely as the frequency source for an RTC. Just don’t expect it to be XTAL accurate over time periods shorter than 64 seconds, and don’t expect to see your crystal frequency change due to the calibration process.
there was a post a while ago abt this, people thought it was tempurature related at first but the time shift I see is very consistent