cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F217 HSE and Timer Sync

PCarn.1
Associate III

I'm working with an STM32F217 and I have a few timer channels setup as sync clocks to regulators (around 1.5 MHz). I'm checking to make sure my sync lines are actually using HSE as a reference clock by looking at the phase drift between my external oscillator output and an STM32 timer output on an oscilloscope. With the amount of drift I'm seeing it doesn't seem like the timers are referencing HSE. I'm confused though because bits 3:2 of RCC_CFGR say I'm referencing my external oscillator as my system clock.

Here are the related register values:

RCC->PLLCFGR = 0x24403c18

RCC->CR = 0x30b6983

RCC->CFGR = 0x940a

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

> external oscillator output

So you're feeding a clock signal into PH0 (in which case HSE_BYP should be set) or are you using a crystal?

Could output HSE on MCO and verify it lines up with your expectations.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

12 REPLIES 12
TDK
Guru

> external oscillator output

So you're feeding a clock signal into PH0 (in which case HSE_BYP should be set) or are you using a crystal?

Could output HSE on MCO and verify it lines up with your expectations.

If you feel a post has answered your question, please click "Accept as Solution".
PCarn.1
Associate III

I have a crystal and function generator that can be switched with a jumper, neither of them are synced with MCO. When I look at MCO I get a 16 MHz signal, which is what HSI is set to. 

RCC->PLLCFGR = 0x24403c18

RCC->CR = 0x30f6983

RCC->CFGR = 0x940a

Select HSE as the MCO1 output in RCC_CFGR. It's HSI by default. You can also look at SYSCLK on MCO2 to verify system clock is actually using HSE, although your registers suggest it is.

Can also check the CSSF bit in RCC_CIR to see if an error on HSE was detected.

Crystal and function generator on the same pin can be causing issues. Certainly seems like a clocking issue.

If you feel a post has answered your question, please click "Accept as Solution".
PCarn.1
Associate III

There are no bits high in RCC_CIR. MCO1 is synced with my input. MCO2, set to SYSCLK, is also synced but for some reason it's a 200 mV signal centered around 2 Volts.

I just had to change my scope settings and the signal looks much better (10x probe vs 1x probe). I was originally assuming the PLL and SYSCLK were not referencing HSE but now I'll start investigating the timer channels to make sure they're referencing SYSCLK.

There's no mux for the timer clock source. If HSE is active and working, I don't see why or how the timer would drift relative to it, assuming timer registers aren't changed.

You could perhaps also show what you mean by "phase drift between my external oscillator output and an STM32 timer output on an oscilloscope". Screenshot or picture or something. I think I understand what you're saying but sometimes the picture can clear up assumptions.

If you feel a post has answered your question, please click "Accept as Solution".
PCarn.1
Associate III

phase-difference.gif

This is sort of what I'm seeing but the phase difference is constantly changing. I'll do more debugging tonight.

Sorry, I am a bit confused:
You want to configure some timers (TIMs) and verify if their generated clock outputs are in sync with the external HSE oscillator? (expecting a constant phase relation?)

If the TIMs and all the TIM blocks get their core clock via HSE -> PLL -> TIM - how could they be in sync if a PLL is involved?

It can only work, if you can grab the TIM clock directly from the HSE input - without any PLL involved.
(a PLL will have a phase offset, and even a phase drift)

Is there an option to select HSE (directly) as clock source for a TIM? If not, e.g. via a PLLx (which comes from HSE via PLLM but after a PLL) - I would assume these signals are never phase synchronized (and the phase can drift).

 

Not sure this really clears much up. Signals you're looking at should be square waves, not sine waves. The figure you attached looks like jitter, not drift. Some amount of jitter is to be expected due to the PLL.

If you feel a post has answered your question, please click "Accept as Solution".