STM32F303 clock startup

[gbigden]

Posted on March 06, 2015 at 15:15

With a clock module connected to the OSCin (HSE) does the chip start up using that or does the internal osc start the MCU and a s/w setup change over to the external clock? Otherwise how does it know what frequency is being input?

#external-clock #clock #stm32f303

[Tesla DeLorean]

Posted on March 06, 2015 at 16:43

STM32 chips always start using the HSI clock, which they know.

You have to manually start all external clocks, and you express their speed to the software/compiler via the HSE_VALUE define, and this way the software can figure out what baud rate divider, etc, to program into the registers by doing the math based on the numbers supplied. If you fail to do that, stuff gets broken.

Some System Loader USB implementations will start external clocks, and benchmark them against the internal clock to pick one of a small subset of supported clock speeds/crystals.

[gbigden]

Posted on March 06, 2015 at 16:46

Thanks. It seems the HSI clock starts first from what I can make out. I want to use a 16.384MHz module to provide a super stable HSE clock. Any problems I am likely to encounter, given that the HSI starts with 8MHz?

[Tesla DeLorean]

Posted on March 06, 2015 at 17:08

Any problems I am likely to encounter, given that the HSI starts with 8MHz?

I don't know, what do you perceive as a threat?

The normal model is to transition to a HSE/PLL based clock via SystemInit() prior to your main() seeing the light of day.

+/-1ppm stability (not accuracy), figuring a TCXO, not sure 16.384 MHz is a standard offering, trying to do telecom? 16.368 MHz would have a lot higher run rates, and you could probably find a +/-0.5ppm

Do you plan on running at the HSE speed? or using the PLL/VCO? I haven't checked the F3, but the others will take a XO input from 1-50 MHz (vs 4-26 MHz for just a crystal).

[gbigden]

Posted on March 06, 2015 at 17:42

I will be using THD3004-16.384MHz temp compensated. Accuracy 0.28ppm and stability 4ppm over 15 years. The major reason for this is that I am measuring a time-of-flight to a resolution of 1ppm, so any drift in the clock really hurts it.

I am assuming I can feed it in directly and do a divide by 2 to make it look like the HSI speed

[waclawek.jan]

Posted on March 06, 2015 at 17:53

> I will be using THD3004-16.384MHz temp compensated. Accuracy 0.28ppm and stability 4ppm over 15 years.

> The major reason for this is that I am measuring a time-of-flight to a resolution of 1ppm, so any drift in the clock really hurts it.

Doesn't that call for short-term stability, rather than absolute precision and long-term stability? Of course the latter can't hurt, and I am not really interested in your project, just commenting.

Also, do you plan to use the PLL? If so, have you considered its jitter?

JW

[Tesla DeLorean]

Posted on March 06, 2015 at 18:05

I am assuming I can feed it in directly and do a divide by 2 to make it look like the HSI speed

But what in your model does doing that buy you? The faster clock would give you better granularity.

Looks to be one of PLE's standard builds, figure it targets 2.048 MHz telco applications.

[Tesla DeLorean]

Posted on March 06, 2015 at 18:10

Doesn't that call for short-term stability, rather than absolute precision and long-term stability?

The short term is probably tighter, but arguably unknown drift unless calibrated out at time of use. Presumably Gary is going to characterize the delivered part at final test.

[gbigden]

Posted on March 09, 2015 at 09:04

I have assumed that jitter will average out. The typical ToF is in the hundreds of uS and I sample and average that over 100x per second

[gbigden]

Posted on March 09, 2015 at 09:07

What that 16.384 gets me is a cheap(ish) modules. Other frequencies are rather more expensive, especially lower frequency ones