I have a design with a 32.768Khz crystal that is the tuning device for my internal 48Mhz osc. The applicaiton is very high vibration and large temperature swings. I'd like to switch to a newer MEMS clock source. Something like this:
https://www.sitime.com/products/32-khz-oscillators/sit1533It's small, seems to be extremely low power, accurate over range, doesn't require additional components, I get an IO back on my micro if I want it, and tolerance is pretty good.
I've never used one of these. I rarely use 32Khz clocks at all.
- 32Khz is pretty slow. Can I get away with a little extra length away from the micro? (it would make routing easier for me)
- They sell a few drive level options, I'm not sure what I want for an STM32 micro. I think it needs to function in their "analog mode" so not full swing, but does it matter if what the levels are if within spec?
- Anything special I should know?
- 32Khz is pretty slow. Can I get away with a little extra length away from the micro? (it would make routing easier for me)
Yes, but longer/wider traces will increase load capacitance. The I/O line needs to be driven high/low at 32768Hz, so that increases power consumption.
- They sell a few drive level options, I'm not sure what I want for an STM32 micro. I think it needs to function in their "analog mode" so not full swing, but does it matter if what the levels are if within spec?
I think you'll need the full swing version. Then use it in the low speed oscillator mode (not crystal)
The full swing version requires more power since it has to (dis)charge the load capacitance using a greater voltage span.
The datasheet gives some example calculations on how to
estimate these things.
If you don't care much about power consumption, this is essentially all a non-issue..
What is the point of that oscillator? The spec doesn't suggest it does anything special, over a 32768Hz xtal.
That MEMS device isn't very accurate so it is unlikely the application drives any interface which a tight frequency tolerance. I'd use the internal RC oscillator.
What is the point of that oscillator? The spec doesn't suggest it does anything special, over a 32768Hz xtal.
The OP specified
The applicaiton is very high vibration and large temperature swings. The MEMS oscillator is much better than a crystal
over wide temperature ranges and it likely to also be much more shock tolerant.
- They sell a few drive level options, I'm not sure what I want for an STM32 micro. I think it needs to function in their "analog mode" so not full swing, but does it matter if what the levels are if within spec?
If you allow an optional series coupling C, you can work with either full CMOS ip, or lower drive swings.
Check the STM data to see what mode choices you have eg do they have a 1 pin CMOS drive option for 32kHz external ?
That MEMS device isn't very accurate so it is unlikely the application drives any interface which a tight frequency tolerance. I'd use the internal RC oscillator.
Well... Maybe I'm wrong, but...
This is ~20ppm @ 32768 per second over stability and tolerance or so. Compare that say a 25Mhz clock at 150ppm considering the swings and ignoring vibration, it's kind of a big difference, isn't it? And you're saying use the internal osc which is way looser than that, like 2000ppm over temperature which for the application of the USB protocol is unacceptable (it's FS but still!). Isn't that a 0.06% compared to 0.38% off over 1s? IDK, are you sure that MEMS device isn't very accurate?
This device is used to trim the internal 48Mhz osc automatically and continually. In theory, if this clock is 20ppm effective, you should get that percentage tolerance to the trimmed internal RC, constantly adjusted.
But, I love coming here to be told how wrong I am and it happens a lot!
Yes, but longer/wider traces will increase load capacitance. The I/O line needs to be driven high/low at 32768Hz, so that increases power consumption.
I think you'll need the full swing version. Then use it in the low speed oscillator mode (not crystal)
The full swing version requires more power since it has to (dis)charge the load capacitance using a greater voltage span.
The datasheet gives some example calculations on how to estimate these things.
If you don't care much about power consumption, this is essentially all a non-issue..
If you allow an optional series coupling C, you can work with either full CMOS ip, or lower drive swings.
Check the STM data to see what mode choices you have eg do they have a 1 pin CMOS drive option for 32kHz external ?
Yea, I was concerned it wouldn't be a super easy answer. I'll check the datasheet again. ST talks about a digital mode that I considered to be full swing and hard edges, and an analog mode. Because this is the RC-trim source AND the RTC itself, there is a special note about the RTC only running off backup power in "analog mode" which I think is not full swing and not-square-wave (although probably not perfectly sin either).
I'll check.
That MEMS device isn't very accurate so it is unlikely the application drives any interface which a tight frequency tolerance. I'd use the internal RC oscillator.
Well... Maybe I'm wrong, but...
This is ~20ppm @ 32768 per second over stability and tolerance or so. Compare that say a 25Mhz clock at 150ppm considering the swings and ignoring vibration, it's kind of a big difference, isn't it? And you're saying use the internal osc which is way looser than that, like 2000ppm over temperature which for the application of the USB protocol is unacceptable (it's FS but still!). Isn't that a 0.06% compared to 0.38% off over 1s? IDK, are you sure that MEMS device isn't very accurate?
This device is used to trim the internal 48Mhz osc automatically and continually. In theory, if this clock is 20ppm effective, you should get that percentage tolerance to the trimmed internal RC, constantly adjusted.
Looking at the MEMS you linked to it says a stability of 75ppm over a more or less commercial temperature range. That isn't good enough for USB either.
Also, from a technical standpoint, creating 48MHz from a 32kHz oscillator needs a pretty good VCO inside the microcontroller. I don't think you'll find that in a microcontroller from ST. I'd expect quite a bit of phase noise (jitter).
Looking at the MEMS you linked to it says a stability of 75ppm over a more or less commercial temperature range. That isn't good enough for USB either.
Also, from a technical standpoint, creating 48MHz from a 32kHz oscillator needs a pretty good VCO inside the microcontroller. I don't think you'll find that in a microcontroller from ST. I'd expect quite a bit of phase noise (jitter).
Yea! You're right. That's 75 stability overall, and ~20 over the temp range. I was looking at a few parts in this range, but I have to agree with your assessment this one I linked to isn't that great. I had some better ones, I'll go see where I went wrong on their part system.
Slight note though, it's not creating the 48Mhz from the 32Khz. It's taking the 48Mhz RC and trimming it to the 32Khz's tolerance.
I doubt the MEMS based oscillator is better than a crystal oscillator. The stability of MEMS is much worse afaik, and when talking "vibrations" - how could be a micromechanical MEMS be better?
Is MEMS the same thing as a ceramic resonator?
I use the latter for cheapness, and small size.
I doubt the MEMS based oscillator is better than a crystal oscillator. The stability of MEMS is much worse afaik, and when talking "vibrations" - how could be a micromechanical MEMS be better?
It could be a matter of construction. I have a gut feeling the old '49' (IIRC) style crystal cases are a lot more susceptible to damage from vibration compared to a modern crystal in 2x2mm (or even smaller) package. IOW: I'd do a bit more investigation into what kind of package style is problematic versus a simplified blanket statement that crystals are problematic in high vibration environments. There have to be solutions for space use for example as the vibrations during launch are extreme.
I'm not sure what I want for an STM32 micro
They have a number of application notes, such as
https://www.sitime.com/support/resource-library/application-notes/an10037-optimized-sit15xx-drive-settings-32-khz-inputsLooking at the MEMS you linked to it says a stability of 75ppm over a more or less commercial temperature range. That isn't good enough for USB either.
How can <100ppm not be good enough when full speed requires +/-0.25% (2500ppm). Even the high speed requirement is above 100ppm (+/-0.05%, 500ppm).
Your problem in getting an internal clock trimmed for usb is most likely not the LSE reference clock, but how well the internal clock can be trimmed. If the internal clock moves 0.5% (5000ppm) for each trim value increment/decrement, then the resolution of trimming becomes kind of coarse for the job.
In practice, I think usb is more tolerant of the (low/full speed) clock than the design requirements, which have to take into account some max number of hubs in a chain, and so on. I had a pic24, which to use the internal clock it had to be routed externally back to the external clock input so it could drive the usb clock (via pll). The SOF was used to trim the internal clock, which worked ok, but manually trimming the internal clock to its max values while testing never resulted in 'losing' the usb functionality either (don't remember what the actual usb clock freqs were, but were quite a bit outside the allowed range at max trim values). This was at normal temperatures, and I am simply pointing out that usb doesn't quit working when you reach the specified tolerance threshold.
I take it you do not want an external crystal for the main clock, but you are trading that problem for a different one (an external low speed clock + code to do trimming). There are also crystal-less mcu's in the stm32 family which are also an option. I would assume one could also do something on your own like I did on the pic24 and use the SOF to trim the internal clock. The best option is probably to just let hardware deal with this- either get a main clock crystal or get a crystal-less mcu.
Your problem in getting an internal clock trimmed for usb is most likely not the LSE reference clock, but how well the internal clock can be trimmed. If the internal clock moves 0.5% (5000ppm) for each trim value increment/decrement, then the resolution of trimming becomes kind of coarse for the job.
In practice, I think usb is more tolerant of the (low/full speed) clock than the design requirements, which have to take into account some max number of hubs in a chain, and so on. I had a pic24, which to use the internal clock it had to be routed externally back to the external clock input so it could drive the usb clock (via pll). The SOF was used to trim the internal clock, which worked ok, but manually trimming the internal clock to its max values while testing never resulted in 'losing' the usb functionality either (don't remember what the actual usb clock freqs were, but were quite a bit outside the allowed range at max trim values). This was at normal temperatures, and I am simply pointing out that usb doesn't quit working when you reach the specified tolerance threshold.
I take it you do not want an external crystal for the main clock, but you are trading that problem for a different one (an external low speed clock + code to do trimming). There are also crystal-less mcu's in the stm32 family which are also an option. I would assume one could also do something on your own like I did on the pic24 and use the SOF to trim the internal clock. The best option is probably to just let hardware deal with this- either get a main clock crystal or get a crystal-less mcu.
Fair point, but the 48Mhz clock has a trim stepping of .175% and a range of +/- 5.5%. If I did the math right... That's approx an accuracy of 0-36ppm off from the 32Khz. So, yes. If you have 25ppm on the LSE and trim the HSE to it, with your resolution, I guess that's a worst case of 61ppm with a lower power usage and a solid temperature curve depending on product. I can get a crystal that is more accurate than that, but requires caps and draws what... 1-2mA or so?
I'm liking some of the MEMS options. Just maybe not that SIT1533 I first selected.
Also, no code for trimming. It's built into at least some STM32s.
Fair point, but the 48Mhz clock has a trim stepping of .175% and a range of +/- 5.5%. If I did the math right... That's approx an accuracy of 0-36ppm off from the 32Khz. So, yes. If you have 25ppm on the LSE and trim the HSE to it, with your resolution, I guess that's a worst case of 61ppm with a lower power usage and a solid temperature curve depending on product. I can get a crystal that is more accurate than that, but requires caps and draws what... 1-2mA or so?
I'm liking some of the MEMS options. Just maybe not that SIT1533 I first selected.
Also, no code for trimming. It's built into at least some STM32s.
Any long term timing needing precision, should be done from the 32kHz side, as the high speed Osc trim steps mean you are never certain of the current offsets.
The MCUs that auto-trim also are often vague on exactly how they do that.
It's going to be fine for UARTS and USB type use.
Also, no code for trimming. It's built into at least some STM32s.
Maybe specify which stm32 you are using/plan to use- your original post mentioned a 48MHz internal clock, I assumed you were talking about an internal 8MHz pll'd to 48MHz, but now it sounds like you have an internal 48MHz HSI, which most likely means crystal-less usb which means you could skip the 32k clock and use SOF to do the clock recovery/CRS. Or maybe this 32k clock is for rtc use also?
Do those devices really maintain "tens of ppm" accuracy/stability during 15000g shock?
There are smart 155mm shells e.g. Excalibur which contain triple INS and GPS, so they must have a CPU running, but that is not the same thing as holding the stability during the 9ms acceleration phase.
Also, no code for trimming. It's built into at least some STM32s.
Maybe specify which stm32 you are using/plan to use- your original post mentioned a 48MHz internal clock, I assumed you were talking about an internal 8MHz pll'd to 48MHz, but now it sounds like you have an internal 48MHz HSI, which most likely means crystal-less usb which means you could skip the 32k clock and use SOF to do the clock recovery/CRS. Or maybe this 32k clock is for rtc use also?
STM32U5 or H5 should be the same system
Yes, 48 HSI, then the LSE is used to automatically trim it. You can also use the USB SOF from incoming messages, but that's a bad idea in my case. So, LSE it is. And yes, LSE for RTC as well as trimming the HSI. I have space for one, not both.
I doubt the MEMS based oscillator is better than a crystal oscillator. The stability of MEMS is much worse afaik, and when talking "vibrations" - how could be a micromechanical MEMS be better?
You need to ask the experts, and the tech is a moving target too....
This example from Sitime :
The quartz oscillator was qualified up to 1500g and the SiTime Endura MEMS oscillators are qualified to. 30,000g.
and more examples here
https://militaryembedded.com/radar-ew/rf-and-microwave/hypersonic-weapons-systems-getting-in-sync-with-mems-based-timing
If the OP needs better ppm, there are SiTime MEMS models that go to 5ppm or even 3ppm
https://www.sitime.com/products/khz-oscillators#cat216
The acceleration shock and vibration are two different things, I would say.
During firing a shell the electronics inside is not working, it starts working some time after (unless it is a simple timing fuse programmed while exiting the muzzle of the barrel). They fired 120mm shells with 4 or 5 vacuum tubes inside during WWII so the modern crystals or MEMS may survive that shock easily..
The vibration means long term smaller periodic acceleration events with higher frequencies, here a MEMS vs crystal comparison would be difficult to make, imho..