stm32f4 discovery wrong core clock

[fabio23]

Posted on January 27, 2014 at 19:37

I'm new on stm32 development and I could be wrong.

I try to test the real core clock of my Stm32f4 discovery, using a modified example of IO_Ttoggle project of  STM32F4-Discovery_FW_V1.1.0, using startup_stm32f4xx.s included without change.

 

the essential part of my changes are

SystemInit();

SystemCoreClockUpdate();

uint64_t timer=SystemCoreClock;

while(1){

while(timer--)

      {

      }

GPIO_ToggleBits(GPIOD,  GPIO_Pin_13);

 timer=SystemCoreClock;

}

but this cycle require 9.x sec and not 1 sec,

 the configuration used was:

stm32f4xxx.h:

&sharpif !defined  (HSE_VALUE)

  &sharpdefine HSE_VALUE    ((uint32_t)8000000) /*!< not 25000000 as in original file */

&sharpendif /* HSE_VALUE */

/*@file    stm32f4xx.h

  * @author  MCD Application Team

  * @version V1.0.0

  * @date    30-September-2011 */

  and the system_stm32f4xx.c generated by the clock configuration tool

 

/*=============================================================================

  *=============================================================================

  *        Supported STM32F4xx device revision    | Rev A

  *-----------------------------------------------------------------------------

  *        System Clock source                    | PLL (HSE)

  *-----------------------------------------------------------------------------

  *        SYSCLK(Hz)                             | 168000000

  *-----------------------------------------------------------------------------

  *        HCLK(Hz)                               | 168000000

  *-----------------------------------------------------------------------------

  *        AHB Prescaler                          | 1

  *-----------------------------------------------------------------------------

  *        APB1 Prescaler                         | 4

  *-----------------------------------------------------------------------------

  *        APB2 Prescaler                         | 2

  *-----------------------------------------------------------------------------

  *        HSE Frequency(Hz)                      | 8000000

  *-----------------------------------------------------------------------------

  *        PLL_M                                  | 8

  *-----------------------------------------------------------------------------

  *        PLL_N                                  | 336

  *-----------------------------------------------------------------------------

  *        PLL_P                                  | 2

  *-----------------------------------------------------------------------------

  *        PLL_Q                                  | 7

  *-----------------------------------------------------------------------------

  *        PLLI2S_N                               | 258

  *-----------------------------------------------------------------------------

  *        PLLI2S_R                               | 3       

*/

 

I tried also to change the manually the

&sharpdefine PLL_M     16

  or

&sharpdefine PLL_P      4

to achive 84MHz  but this have no effect always 9.x sec for every toggle.

 

Using

&sharpdefine PLL_M      16

(@ 84Mhz) and uint64_t timer=168 000 000;

It takes 18.x sec.

 

I think it's impossible that

while(timer--)

takes 10 clocks/cycle.

 

during debugging the section SetSysClock() that say

else

 { /* If HSE fails to start-up, the application will have wrong clock

        configuration. User can add here some code to deal with this error */

 }

 has never been reached, and SystemCoreClock was correctly update douring the test @84 Mhz

it seems that the core clock always run at 1/10 of indicated speed 16.xMhz @168Mhz and 8.xMhz @84Mhz

Where i'm wrong?

#clock #stm32f4

[Tesla DeLorean]

Posted on January 27, 2014 at 21:42

I think it's impossible that

 

while(timer--)

 

takes 10 clocks/cycle.

That would depend a lot on what code the compiler actually generated, the optimization settings, and the fact the CPU doesn't natively support 64-bit math. So perhaps not an assumption you're qualified to make.

If you want to measure the internal clocks, then output them via the MCOx pins and look at them on a scope.

If you want to mark time, use a timer, or SysTick reference which has some defined basis rather than some arbitrary software delay loop.

[fabio23]

Posted on January 28, 2014 at 08:37

Thanks Clive1!

(

these tests

were done

waiting for

the oscilloscope

that

is

lost somewhere

in the world

)

[Tesla DeLorean]

Posted on January 28, 2014 at 15:19

For delays that relate to the CPU clock speed, consider using DWT_CYCCNT

//******************************************************************************
volatile unsigned int *DWT_CYCCNT = (volatile unsigned int *)0xE0001004; //address of the register
volatile unsigned int *DWT_CONTROL = (volatile unsigned int *)0xE0001000; //address of the register
volatile unsigned int *SCB_DEMCR = (volatile unsigned int *)0xE000EDFC; //address of the register
//******************************************************************************
void EnableTiming(void)
{
*SCB_DEMCR = *SCB_DEMCR | 0x01000000;
*DWT_CYCCNT = 0; // reset the counter
*DWT_CONTROL = *DWT_CONTROL | 1 ; // enable the counter
}
//******************************************************************************
void TimingDelay(unsigned int tick)
{
unsigned int start, current;
start = *DWT_CYCCNT;
do
{
current = *DWT_CYCCNT;
} while((current - start) < tick);
}
//******************************************************************************