Tobias Have

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 8 months ago.

How does the SystemCoreClock value get changed?

I use an FRDM-K64F rev. D, MBED libraries rev 104. I am controlling some motor drivers from a pc serial port console over UART4 of the K64F.

The program reports SystemCoreClock to the serial port on startup. This works as expected, reports 120000000 Hz.

But if I move it further down the code, or add another call to this in my main loop, it reports 117470309 Hz.

When I measure a FastPWM output, with oscilloscope, I can not measure any difference in output period, though. 10.000 kHz regardless of reported core clock.

My output function:

void pc_write_int(char name[], int value)
{
    int i;
    snprintf(cmd_outbuf, cmd_bufsize, "%s = %d", name, value);
    for(i=0; i<cmd_bufsize; i++) {
        if(cmd_outbuf[i]>0) {
            pc.putc(cmd_outbuf[i]);
            cmd_outbuf[i]=NULL;
        }
    }
    pc.putc(13);
}

I call this with:

    pc_write_int("System Clock (Hz)", SystemCoreClock);

The program also uses several InterruptIns, FastPWM, SDFileSystem, I2C. These are always declared and initiated before first use of SystemCoreClock.

Can anybody figure out what is happening?

Now, adding a single line (toggling a DigitalOut on PTB23) made the SytemCoreClock report 117470309. When removing this line again = reverting to exact same code that just previously worked, SystemCoreClock stays at 117470309.

posted by Tobias Have 12 Aug 2015

Just adding an outcommented line <<code>> //enb1=1; <</code>> can also generate the error. So it seems very random and not related to actual timer settings or conflicts.

posted by Tobias Have 12 Aug 2015

FastPWM uses SystemCoreClock to base its PWM values on, so if the clock actually changes, it would adapt its settings if you call the .period functions again.

I am planning to have a look at this later, since it is a bit weird. What I can imagine is that originally it gets set to the ideal 120MHz, and then something calls SystemCoreClockUpdate(). Then question 1 is if that actually returns the value you report, question 2 is which part would be calling SystemCoreClockUpdate().

posted by Erik - 13 Aug 2015

Looks like that. 120MHz is set by default so reading that value can give that result if noone updated the clock calling SystemCoreClockUpdate. Because the coreclock value is read in SystemCoreClockUpdate(), from registers.

posted by Martin Kojtal 13 Aug 2015

I setup FastPWM period and pulsewidth in ticks only, so a change in core clock should affect the period measured with oscilloscope. This is not the case, so it seems the clock is not actually changing.

Also, I can compile the exact same source code twice, and get different reported clock frequencies. After last weeks maintenance, I noticed that the compiler behaved a bit weird and sometimes used the previous versions of source files without any error messages or warnings. Could this be related?

posted by Tobias Have 13 Aug 2015
Be the first to answer this question.