CPU crystal "pull" range and how critical are the caps, for e.g. USB FS

[peter-h]

I have not been able to find the 1.5mA version.

It is an excellent point in that while an xtal should gradually start up oscillating due to the feedback around the inverter stage (and not at some weird frequency) you can never know what glitches an oscillator might produce, with the potential to lock up the CPU. After all, using out of spec clock input has been one of the ways to crack smartcard chips.

[PCB.Wiz]

I have not been able to find the 1.5mA version.

That 1.5mA was my bench measured typical value (no load).  I think the specs say 4mA max.
The programmable xtal oscillator modules include a PLL/VCO, so their currents are higher.
eg a 680PR model here says 15mA max and measures ~5.4mA

[faststoff]

Substantial extra cost; otherwise I agree

The interesting thing is that nobody has posted their results of a "proper" xtal evaluation, over a range of cap values and Rext, to find out where it stops working.

The most useful data is from PCB.Wiz, regarding the delta f due to cap variation.

I did testing over a wide cap range and for several Rext values a while back for said products. When time permits, I can maybe do a writeup of some sorts.

The exact cap value are important for the 32kHz crystal, especially if the product is not interacting with devices that can correct its clock on a regular basis. I have had to deal with a product that was, on average, 40 ppm off (note: each board will have individual variations inside the crystal specced variance, and the target of setting load caps is to center an ensemble of several boards around 0). Now, while that might not sound like much, it amounted to more than 100 seconds per month drift for all products. Without going into detail, this led to a series of secondary problems for the product.

I have a feeling that most people don't bother, copy some appnote / dev board for the values, and 99% of the time it works.

I can confirm that this is exactly what most people do, and the crystal manufacturers know it. The crystals you see on devkits from microcontroller manufacturers are usually given free-of-charge by the manufacturer to ensure that exactly their crystal is in that position, ready to be copied. They will even offer to do the design-in of their crystal into an existing line of devkits if that can make it easier to switch. Don't ask me how I know

[peter-h]

Without going into detail, this led to a series of secondary problems for the product.

Yes; this is another big "embedded problem"... no way to get time data without internet (NTP), or GPS, or radiocode, or even GSM. In my last design I used NTP or GPS. None of that is really cheap. An xtal alone will always be poor (20ppm, etc) unless you do factory cal, preferably over temperature. But you need a time sync method anyway, unless the RTC draws a small enough current to run for literally years from a 2016-sized cell, and AFAIK none of the CPU RTCs are anywhere near good enough (1uA plus).

The crystals you see on devkits from microcontroller manufacturers are usually given free-of-charge by the manufacturer to ensure that exactly their crystal is in that position, ready to be copied.

That's funny, and those I've come across were xtals you would never use in production unless you were stupid (e.g. 1k price of €0.50). The xtal mfgs must also be handing them out to get the P/Ns into the CPU mfg appnotes. Most of the xtals in the STM appnotes are unusuable for production.

[T3sl4co1l]

Well, how do the automotive folks do it?  I haven't had a car lose more than minutes over the time I've owned it.  In all weather year round.

Well, plus or minus exactly one hour technically, because we still live under the hell of daylight savings, but besides that...

Tim

[JPortici]

Well, how do the automotive folks do it?  I haven't had a car lose more than minutes over the time I've owned it.  In all weather year round.

Well, plus or minus exactly one hour technically, because we still live under the hell of daylight savings, but besides that...

Tim

Depnding on brand, GPS (15yo VAGs did that) or internet.
My almost 10 years old octavia has the option to syncronize the clock for time keeping via GPS, the much older Fiat Punto i had before didn't have anything but i don't remember losing more than one minute every six months, good enough if you have to adjust it for DST anyway
Wouldn't be surprised if radio clock was used back then

IME: crystals (or MEMS) to be used if FRC doesn't meet expectations (and unless CAN or ethernet are involved, FRC is usually much more than good enough)

[peter-h]

Well, how do the automotive folks do it?  I haven't had a car lose more than minutes over the time I've owned it.  In all weather year round.

I had a quick read of some appnotes a while ago.

In production, it's not hard to do a proper cal. Modern RTCs have a cal feature, whereby a counter adds or subtracts a millisecond or so every so often. Or you can do it in software; car clocks usually show just hh:mm so you just mess with the seconds. This kind of cal can be done in an instant, and anybody in that business must be doing it because the usual ~20ppm watch xtal is way too crap. In the old days you had a trimmer cap on the xtal, adjusted with a servo screwdriver.

Ideally you do a two point cal but I don't know how that can be done quickly because you need to elevate the temperature a bit. You would then use a temp sensor to regulate the adjustment; most CPUs now have a temp sensor.

The other thing is that in a car you have loads of battery capacity So you can use a decent xtal - say 4MHz. These are much better over temp. This is nothing new; in the 1960s Bulova were promoting "more accurate" quartz watches which used such an xtal. May have been 2MHz. I developed a product many years ago which used a special Swiss xtal, 2MHz, for a specific reason. 1MHz was not good, 4MHz could not be used for some other reason. The 2MHz one (I still have a bag of them - SMT in a glass case) was perfect for an accurate and fairly low power RTC, implemented in a mixed-signal ASIC I did the design for.

I think every mfg does a 1 point cal which is instant, and this is probably good enough. I suspect a 2 point cal is of the same order as xtal ageing. This is sort of related
https://www.eevblog.com/forum/chat/cheapest-way-to-get-datetime-from-gps/

Depnding on brand, GPS (15yo VAGs did that) or internet.
My almost 10 years old octavia has the option to syncronize the clock for time keeping via GPS, the much older Fiat Punto i had before didn't have anything but i don't remember losing more than one minute every six months, good enough if you have to adjust it for DST anyway
Wouldn't be surprised if radio clock was used back then

It would be zero if they used GPS or timecode

[JPortici]

It would be zero if they used GPS or timecode

as a matter of fact, my current old car has zero

[PCB.Wiz]

I have had to deal with a product that was, on average, 40 ppm off

40ppm was not a large error, years ago, when 100ppm and 50ppm crystal were common / cheapest.
These days, you can usually find 10ppm @ 25'C spec crystals, or oscillators, so at least the initial setup can be tighter.

Of course, if you want wide temperature tolerance, the crystal ppm/T curves then start to matter.

[faststoff]

I have had to deal with a product that was, on average, 40 ppm off

40ppm was not a large error, years ago, when 100ppm and 50ppm crystal were common / cheapest.
These days, you can usually find 10ppm @ 25'C spec crystals, or oscillators, so at least the initial setup can be tighter.

Of course, if you want wide temperature tolerance, the crystal ppm/T curves then start to matter.

I agree, the 40 ppm is by itself not that big, and any system relying on a >=10ppm crystals for timekeeping should have some idea of how to handle clock drift if accurate timekeeping is important IMHO. In this case, it created secondary problems as the system around the product was not rigged well to handle clock correction easily once the product was out in the field, and thus we would start to get datalogs with quite unpredictable timestamps as units accumulated months - years worth of 40 ppm drift.