The hardware CPU core clock is 168 MHz while core clock is set at 53.76 MHz. Why?

[jim_wei]

Posted on September 13, 2013 at 06:06

I am experimenting with the discovery board for STM32F407 using Keil's training material:

http://www.eng.auburn.edu/~nelson/courses/elec5260_6260/STM32F4-Discovery%20Keil%20Training.pdf

On page 10 of this training document, it shows that the core clock setting in the trace tab is 53.76 MHz.  I thought this has to be the same as the CPU core clock which is 168 MHz and yet this setting works.  If I change it to 168 MHz to match the CPU core clock, it would not work (I can not see the data in Analyzer if I change to 168 MHz).  Can anyone tell me why. 

Thanks.

jim

[Tesla DeLorean]

Posted on September 13, 2013 at 12:42

Because presumably some of the projects assume a 25 MHz external clock, and the Discovery has an 8 MHz one. (168 / 25) * 8 = ?

You'd need to look at HSE_VALUE, and the PLL settings in system_stm32f4xx.c, and perhaps the README.TXT associated with the project. See also pg 23 of document cited.

Either way the value in the Trace pane needs to correlate with the ACTUAL frequency the core is running at, which you could verify using the MCO pin on the chip.

[jim_wei]

Posted on September 15, 2013 at 17:00

Thanks clive1 for pointing at the right direction.  I made the following changes:

1) In file ''stm32f4xx.h''

change

#define HSE_VALUE    ((uint32_t)25000000)

to

#define HSE_VALUE    ((uint32_t)8000000)

2) In file ''system_stm32f4xx.c

Change

#define PLL_M      25

to

#define PLL_M      8

3) In file RTX_Conf_STM32F4.c

Change

 #define OS_CLOCK       53760000

to

 #define OS_CLOCK       168000000

4) Set the ''Core Clock'' to 168000000 in the Trace Tab of Cortex-M Target Driver Setup

Ran the program,  the data in the Analyzer was completely srewed up.  I was able to get a nice sine wave previously but just wrong frequency.  

I am wondering if there are more changes in addition to the above four changes I made.  

I would appreciate it if someone could shed some light on this.

Jim

 

[Tesla DeLorean]

Posted on September 16, 2013 at 12:24

Generally I look to push in HSE_VALUE via the command line of the compiler.

system_stm32f4xx.c also has a SystemCoreClock value. As indicated before if you are unsure of what the clocks are doing internally, use MCO(1) or MCO2 to export them. You can also output the internal clock settings via a debug/diagnostic message.

If you are using timers, check very carefully the prescaler and period values being programmed in, and how they relate the the APB1/APB2 bus to which the TIM unit is attached.

[jim_wei]

Posted on September 17, 2013 at 04:24

Hello clive1,

Thanks for the tips.  I think the problem might have been caused by the settings or hardware of the debugger, or simply becuase the SWV does not have enough bandwidth to handle the data rate that I need. 

I am using RTX with a 10 ms OS_TICK with an interrupt of 20 us from Timer 2.  The interrupt service routine just reads a data point which is an array of constant of 32 bit Integer.  If I extend the interrupt period to 40 us, the Analyzer shows the correct waveform.  At 20 us, the waveform is totally wrong. 

Jim

[dthedens23]

Posted on September 17, 2013 at 23:41

RTX does have the concept of ISR that are outside the RTOS framework.  They cannot call RTOS services, but something that fast might be better outside the context switching time of the RTOS.

you can always buffer up a bunch into a ringbuffer and when near full, the hardware ISR can fire a software interrupt and this ISR is within the RTOS.  This interrupt then empties the ring buffer.  I've done it before for bursty peripherals.