cancel
Showing results for 
Search instead for 
Did you mean: 

STM3210C - Clock Frequency Irregularites

antoniocorregedor
Associate II
Posted on April 16, 2012 at 22:16

Hi all,

I am currently using the STM3210C evaluation board and have discovered something which is puzzling, and has to do with the clock frequencies.  I am currently using Atollic to program the board and have initialised the micro by using the ''SystemInit()'' function and have determined that the following clock frequencies have been set by calling the ''RCC_GetClocksFreq()'' function:

  • SYSCLK = 72 MHz
  • HCLK = 72 MHz
  • PCLK1 = 36 MHz
  • PCLK2 = 72 MHz
  • ADCCLK = 18 MHz
With the above frequencies I am able to determine for example, what preload values I require in order to generate an interrupt at a specific interval.  I first noticed that the clock frequencies were not as stated above when I configured the SysTick interrupt.  I configured SysTick by calling ''SysTick_Config()'' which sets the SysTick counter clock source to be the core clock source (HCLK). 

However with the use of an oscilloscope I discovered that sending a value of 172249 to the ''SysTick_Config()'' function produces an interrupt of 20 ms (50 Hz).  This means that the SysTick counter clock is set to 8.612450 MHz and not 72 MHz.  I even ensured that the SysTick counter clock was set to HCLK by calling ''SysTick_CLKSourceConfig( SysTick_CLKSource_HCLK )'' after the ''SysTick_Config(172249)'' function.

I experienced the same behavior when setting up TIM2.  According to the data sheet the APB1 is clocked at the same frequency as PCLK1; which should be 36 MHz.  However upon doing similar testing I have discovered that the TIM2CLK is set to 8.61245 MHz.

Can anyone help me explain this behavior, or help me look for a command that could be possibly setting all the clocks to a frequency of 8.61245 MHz.  It sounds like they are in their default reset mode, but this does not make sense because when I call ''RCC_GetClocksFreq()'' it indicates that the clocks have been set accordingly. 

With the use of an oscilloscope I have tailored my code and have it working correctly but I would like to know why I am experiencing this behavior.  Thanks in advance for your help.

Kind Regards,

  Tony

#stm3210c-eval
7 REPLIES 7
Posted on April 16, 2012 at 23:51

Wouldn't this simply be because SysTick clocks at 9 MHz? All of ST's references indicate that it clocks with HCLK / 8 by default, but can be HCLK. This is done no doubt because the counter is only 24-bits wide.

APB1 = PCLK1

APB2 = PCLK2

AHB = HCLK

A TIMCLK derived from an APB1 clock of 36 MHz (72 DIV 2), will actually be 72 MHz as it won't be prescaled. Refer to the clock tree diagram.

If you really believe there is a clocking problem, you should start by measuring the external oscillator (HSE), and also be exporting your internal clocks via MCO.

If your serial ports work at the right baud rates, it would indicate the hardware and software are in agreement about what frequencies it's actually working with.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
antoniocorregedor
Associate II
Posted on April 17, 2012 at 08:09

Clive,

Thanks for your quick reply.  I also thought that the SysTick clock is divided by 8 by I run ''SysTick_CLKSourceConfig( SysTick_CLKSource_HCLK )'' to ensure that the SysTick clock is set at 72 MHz; which as can be seen from my results it is not.

This also does not explain why my TIMCLK is sitting at 8.61245 MHz?  What could possibly be causing this?

I will try your recommendations for checking to see if there is a clocking problem.

Posted on April 17, 2012 at 14:05

You need to start by confirming what your input clocks are, and then that the PLL settings are correct.

You need to confirm if the external oscillator is actually 8 MHz, ST has some designs that use 25 MHz. You need to check the source, includes, IDE, or compiler command line to confirm what HSE_VALUE is set to, as it should match the input clock setting. Check also that the correct STM32F architecture has been selected. ie Connectivity vs Medium density or whatever.

Alternatively you could HSI which should always be 8 MHz.

If the PLL is run at overrated speeds (ie 25 * 9) the operation is probably undefined.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
antoniocorregedor
Associate II
Posted on April 17, 2012 at 21:48

Clive,

Again thanks for your suggestions, I will run through them and will let you know what I discover.

antoniocorregedor
Associate II
Posted on April 23, 2012 at 07:26

I have managed to resolve the issue, once I checked through the code (and found nothing wrong), I discovered that the crystal on the board was wrong.  The board is suppose to come with a 25 MHz crystal but for some weird reason I have a 6 MHz crystal.  Once I accounted for this, my code is now working correctly.

I do however have another question which I was hoping could be cleared up.  I know that if the APB prescaler is 1, that the peripheral timers runs at PCLK, other wise they run at 2 * PCLK.  In my case the PCLK is set to 36 MHz, which is within the maximum specification given in the data sheet.  What I would like to know is if it is okay/safe to have my peripheral timers running at 72 MHz (i.e. at 2*PCLK)?

Posted on April 23, 2012 at 15:42

The Bus side of the timer would be running at 36 MHz, but the counter and internal logic are rated for 72 MHz operation, and running there. Having a high input frequency is helpful as it keeps the granularity small, allows a larger sampling rate for inputs, a counters the lameness of the the integer prescale. Still, in some circumstance you will need to run the part at sub-optimal speeds, or with ''magic number'' crystals in order to get the timers to generate specific frequencies. ie try getting 256 KHz out with a 72 MHz clock source.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
antoniocorregedor
Associate II
Posted on April 24, 2012 at 14:30

Oh I see, thanks Clive for clearing that up.