How to measure clock frequency inside of MCU?

[matic]

Posted on December 29, 2015 at 16:06

Hi.

I would like to measure different clock sources with TIM16 and MCO as it is described in reference manual for STM32F303 uC, which I am using.

I configured TIM16 input capture from remap (in TIM16->OR register), but I am not sure how exactly this measuring works. In the reference manual, there is no extensive description. Could someone describe how this works please. I would be very grateful. Short description of this approach is in RM on pages 122 and 136.

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00043574.pdf

Or do you have any other suggestion how to measure clock with minimum CPU usage? Actualluy I don't have to know exactly what the frequency is, but have to know when something goes wrong (if frequency is not in the specified range).

Thanks a lot.

[Nesrine M_O]

Posted on December 29, 2015 at 17:12

Hi obid.matic,

You can easily output the system clock on an MCO pin which should be configured as alternate function.

I recommend you to have a look to the RCC_ClockConfig example under the STM32F3 cube firmware:

STM32Cube_FW_F3_V1.4.0\Projects\STM32F3Discovery\Examples\RCC\RCC_ClockConfig

In this example the SYSCLK is outputted on the MCO pin(PA.08).

-Syrine-

[matic]

Posted on December 29, 2015 at 22:09

Thank you Syrine, but that's not exactly what I want. I don't want to measure clock externally. I would like to implement some kind of built-in safety mechanism, which would check clock internally - with minimum CPU usage, because this would be only for error control. So, it could be possible to measure clock only once in a while. Maybe once every ten seconds or even more.

[Tesla DeLorean]

Posted on December 29, 2015 at 23:12

I don't want to wade into this too deep, but the basic premise with the STM32 timing internal signals is that you either a) time the period of 1, 2, 4 or 8 cycles of a slower clock in ticks of a faster clock. ie I take LSI and count the ticks on an 8 MHz LSE clock between TWO sequential rising edges. If LSI is 40 KHz I'd expect to see 8000000/40000 ticks, ie advance 200 ticks give or take. If I prescale the INPUT by 8, I'd expect to see 1600 ticks, or estimate the percentage error. Here the time base is left to free run in a maximal mode, and you use Input Capture to time stamp edge events. You take two measurements A, and B from TIMx->CCR1, then the ticks between them is B-A.

Or b), if applicable to this specific timer, would be to use it in External Clock mode, where you are counting pulses on the input channel. Then you'd read your values from TIMx->CNT on a 1 Hz interrupt (say 1000x 1ms SysTick), the B-A value for a 40 KHz clock should yield 40000 ticks. If you fed it an 8 MHz clock you'd expect it to advance 8000 ticks at each 1ms SysTick. You'd want to use independent clocks for this to work, and you'd want the most accurate clock source to quantify the less accurate ones.

[matic]

Posted on December 30, 2015 at 07:39

Thanks Clive.

So, for faster clocks such as HSE (16MHz) and SYSCLK (72MHz), I should use the second approach. Which timer (clock) would be appropriate as a clock source - HSI or LSI? Which one is more accurate?

One more thing. MCO is connected on TIM16 in my case. Does it mean that TIM16 could run on MCO source as in External clock mode?

[Nesrine M_O]

Posted on December 30, 2015 at 11:13

Hi obid.matic,

You can start from the IWDG_Reset project under STM32F3 cube firmware: STM32Cube_FW_F3_V1.4.0\Projects\STM32303C_EVAL\Examples\IWDG\IWDG_Reset

In fact the example shows how to configure TIM16 to measure the LSI frequency as the LSI is internally connected to TIM16 CH1.

The LSI measurement using the TIM16 is described below:

  - Configure the TIM16 to remap internally the TIM16 CH1 Input Capture to the LSI clock output.

  - Enable the TIM16 Input Capture interrupt: after one cycle of LSI clock, the period value is stored in a variable and compared to the HCLK clock to get its real value.

-Syrine-

[matic]

Posted on December 30, 2015 at 14:16

Thanks Syrine.

In this example TIM16 runs on 72 MHz and MCO (measured signal) is connected to its Input channel. But this would work only if measured signal (LSI in that case) has much lower frequency than 72 MHz. Am I right?

What are the possibilities for measuring high speed clocks as SYSCLK or PLL clock? As Clive said, it would be possible to count ticks in a certain time period. But then timer has to be configured in External clock mode. Is possible to configure any timer that it counts on different internal clocks?

[Tesla DeLorean]

Posted on December 30, 2015 at 14:54

Quick skim of the manual suggests External Count mode isn't supported on this timer. Perhaps you can get a signal to another pin?

72 MHz is a bit high to measure the period. If I were trying this I'd set the Input prescaler to 8 and use the DMA with TIM16_CH1 to sample multiple triggers. I'd check if I could use the MCO to drop the frequency further.

[matic]

Posted on December 30, 2015 at 16:45

Probably it would be the easiest way to connect MCO pin (PA8) with its neighbor (PA9) and set it as a Timer Input 2 (TI2FP2) on TIM1. Thus, CNT value in a known time period represent a frequency of a signal which is outputed on MCO pin.

Now I have another question regarding timer which should be used as a base timer. Is possible that a specific timer runs on internal clock (LSI or HSI), while everything else

runs normaly on a HSE oscillator (through PLL)?

[Tesla DeLorean]

Posted on December 30, 2015 at 19:40

Well the manual documents the available functionality. My reading of it suggests I can clock the TIM16 via the PLL/VCO at up to 144 MHz or off APB2.

The system doesn't have to run off the PLL, but that causes a bit of a clock inversion. You'll want to experiment.

[matic]

Posted on December 31, 2015 at 00:01

TIM16 couldn't be clocked at 144 MHz in F303CB part, which we have due to size restrictions. This is true only for larger packages - 64 pins and above. In F303CB TIM1 and TIM8 can be clocked at 144 MHz.

Thank you all for the suggestions. I will try to make something.