MKL27 CLKOUT has wrong Bus frequencies?

[bobpaddock]

I'm using the MKL27 and wanted to confirm I had programmed MCG_Lite correctly.

I am not understanding the frequencies I'm seeing on CLKOUT when I select Bus as the output,

they are not integer divisions or multiples of the selected clock sources, which makes no sense to me.
Does CLKOUT[Bus] in fact work on the MKL27 or have I done something wrong in my code below?

My board has a external 10 MHz Osc.

SIM_CLKDIV is set to divide the CPU Core by two to give Core Clock/2 on Bus.

SIM_SOPT2_CLKOUTSEL(  2U ) |     /* 0:None, 2:Bus, 3:LPO-1kHz, 4:IRC8M/LIRC_CLK, 6:OSCERCLK, 7:IRC48M */

If I set:

SOPT2_CLKOUTSEL to 3 I get 1.01 kHz..

SOPT2_CLKOUTSEL to 4 I get 7.99 MHz,

SOPT2_CLKKOUTSEL to 6 I get 9.9999... MHz

SOPT2_CLKOUTSEL to 7 I get 48 MHz.

All those do exactly what I expect.

Now if I sent SOPT2_CLKOUTSEL to 2, Bus Out, with a source of:

IRC48M I get 48 MHz on CLKOUT when I expect to see 24 MHz.

OSCERCLK (10MHz) I get a frequency wondering between 13 and 16 MHz spending most of its time at 15.2 MHz.  I expect 5 MHz.

IRC8M with FCRDIV set to /1 I get 11.98 MHz when I expect 4 MHz.

What is going on here?

Here is my code:

void clock_destructor_150( void ) ATTR_DTOR( 150 );

void clock_destructor_150( void )

{

  LED_HEAT_GRN_ASSERT(); /* Turn on Green LED */

  SIM_CLKDIV1  = (

                  SIM_CLKDIV1_OUTDIV1( 0U ) |   /* Divide MCGOUTCLK by /1  Divide value for the core/system clock, */

                  SIM_CLKDIV1_OUTDIV4( 1U )     /* Divide MCGOUTCLK by /2  Bus and Flash clock divider.            */

                 );

  /*

   * Maximum frequency limitations for VLPR mode is as follows :

   • the core/system clocks are less than or equal to 4 MHz, and

   • the bus and flash clocks are less than or equal to 1 MHz

  */

  /*

   * To select other clock sources, the mode must be set to HIRC

   * before changing to an other mode.

   */

  MCG_SC    = MCG_SC_FCRDIV( 0U );      /* Select FCRDIV divided by 0:/1, 1:/2, 2:/4, 3:/8, 4:/16, 5:32, 6:64, 7:128 */

  MCG_MC    = (MCG_MC_HIRCEN_MASK|MCG_MC_LIRC_DIV2( 1U )); /* High-frequency IRC Enabled.  LIRC divided by 0:/1, 1:/2, 2:/4, 3:/8, 4:/16, 5:32, 6:64, 7:128 To match Bus.  Use MCGIRCLK for peripherals */

  MCG_C1    = (

               MCG_C1_CLKS( 0U )   |    /* 0:HIRC, 1:LIRC2M or LIRC8M mode, 2:External Clock */

               MCG_C1_IRCLKEN_MASK      /* Internal Reference Clock LIRC enabled */

              );

  /*

   * Clock Mode Status.  This field does not update immediately after

   * a write to MCG_C1[CLKS] due to domain synchronization.

   *

   * Check MCG_S[CLKST] to confirm HIRC clock source is selected

   */

  delay_ms( 5UL );

  while( (0U << MCG_S_CLKST_SHIFT) != MCG_S_CLKST( 0U ) )

    {

      nop();

    }

  /* Now running at 48 MHz */

  OSC0_CR   = 0U;    /* External reference clock is inactive */

  CLK_OE_DEASSERT(); /* Power down the  Osc. */

  SIM_SOPT2 = (

               SIM_SOPT2_TPMSRC(     0U ) |     /* 1:IRC48M/MCGPCLK, 2:OSCERCLK, 3:IRC8M/MCGIRCLK: Clock feeds the TPM clock */

               SIM_SOPT2_LPUART0SRC( 0U ) |     /* 1:IRC48M/MCGPCLK, 2:OSCERCLK, 3:IRC8M/MCGIRCLK: Clock feeds LPUART0 baud rate generator */

               SIM_SOPT2_LPUART1SRC( 0U ) |     /* 1:IRC48M/MCGPCLK, 2:OSCERCLK, 3:IRC8M/MCGIRCLK: Clock feeds LPUART0 baud rate generator */

               SIM_SOPT2_CLKOUTSEL(  2U ) |     /* 0:None, 2:Bus, 3:LPO-1kHz, 4:IRC8M/LIRC_CLK, 6:OSCERCLK, 7:IRC48M */

               SIM_SOPT2_USBSRC_MASK            /* 0:External bypass clock (USB_CLKIN), 1:IRC48M */

              );

// CLKOUT[Bus] gives 48 MHz at this point should be 24 MHz.

  /* Switch to 8MHz internal: */

  MCG_C2    =  MCG_C2_IRCS_MASK;        /* Low-frequency Internal Reference Clock, Select LIRC 8 MHz */

  MCG_C1    = (

               MCG_C1_CLKS( 1U )   |    /* 0:HIRC, 1:LIRC2M or LIRC8M mode, 2:External Clock */

               MCG_C1_IRCLKEN_MASK      /* Internal Reference Clock LIRC enabled */

              );

  /*

   * Clock Mode Status.  This field does not update immediately after

   * a write to MCG_C1[CLKS] due to domain synchronization.

   *

   * Check MCG_S[CLKST] to confirm LIRC clock source is selected

   */

  delay_ms( 5UL );

  while( (1U << MCG_S_CLKST_SHIFT) != MCG_S_CLKST( 1U ) )

    {

      nop();

    }

  MCG_MC    = MCG_MC_LIRC_DIV2( 1U );   /* High-frequency IRC disabled.  LIRC/2 = 4MHz to match Bus.  Use MCGIRCLK for peripherals */

// CLKOUT[Bus] gives 11.99 MHz at this point should be 4 MHz.

  /* The SOPT1 register is only reset on POR or LVD: */

  SIM_SOPT1 = 0U; /* LPO */

  SIM_SOPT2 = (

               SIM_SOPT2_TPMSRC(     0U ) |     /* 1:IRC48M/MCGPCLK, 2:OSCERCLK, 3:IRC8M/MCGIRCLK: Clock feeds the TPM clock */

               SIM_SOPT2_LPUART0SRC( 0U ) |     /* 1:IRC48M/MCGPCLK, 2:OSCERCLK, 3:IRC8M/MCGIRCLK: Clock feeds LPUART0 baud rate generator */

               SIM_SOPT2_LPUART1SRC( 0U ) |     /* 1:IRC48M/MCGPCLK, 2:OSCERCLK, 3:IRC8M/MCGIRCLK: Clock feeds LPUART0 baud rate generator */

               SIM_SOPT2_CLKOUTSEL(  0U ) |     /* 0:None, 2:Bus, 3:LPO-1kHz, 4:IRC8M/LIRC_CLK, 6:OSCERCLK, 7:IRC48M */

               SIM_SOPT2_USBSRC_MASK            /* 0:External bypass clock (USB_CLKIN), 1:IRC48M */

              );

  for(;;)

    {

      LED_HEAT_GRN_TOGGLE();

      delay_ms( 100U );

    }

}

[kerryzhou]

Hi Bob Paddock,

      I test your question on our FRDM-KL27, because this board don't have the external 10Mhz crystal, then I just test the HIRC and LIRC, the clock is configured like this :

HIRC

    core clock: 48Mhz, bus clock: 24Mhz

LIRC

    core clock: 8Mhz, bus clock 4Mhz

  Then I output the bus clock to CLKOUT(PTC3), when choose HIRC, then the bus clock output 24Mhz; When choose LIRC, then the bus clock output 4Mhz on PTC3.

The attachments are the test project based on KDS3.0 and KSDK1.3.0, you can test on your side, and check your configurations.

Wish it helps you!

If you still have question, please contact me!

Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bobpaddock]

Jingjing Zhou wrote:

Hi Bob Paddock,

      I test your question on our FRDM-KL27,

...

The attachments are the test project based on KDS3.0 and KSDK1.3.0, you can test on your side, and check your configurations.

Thank you.

Your KDS generated code reduces to this:

[code]

  SIM_CLKDIV1  = 0x00010000U;   /* SIM_CLKDIV1: OUTDIV1=0,OUTDIV4=1 */

  SIM_SOPT1    = 0x000C0000U;   /* SIM_SOPT1: OSC32KSEL=3,OSC32KOUT=0 */

  SIM_SOPT2    = SIM_SOPT2_CLKOUTSEL( 2U );/* 0:None, 2:Bus, 3:LPO-1kHz, 4:IRC8M/LIRC_CLK, 6:OSCERCLK, 7:IRC48M */

  MCG_MC       = 0x80;          /* MCG_MC: HIRCEN=1,HIRCLPEN=0,LIRC_DIV2=0 */

  PORTC_PCR3   = PORT_PCR_MUX( 5U ); /* Set PTC3 Pin Mux Control Alternative 5 [CLKOUT] */

  GPIOC_PDDR  |= (1UL << 3UL);       /* Enable output on pin */

  MCG_SC       = 0U;            /* MCG_SC: FCRDIV=0 */

  MCG_C1       = 0x42U;         /* MCG_C1: CLKS=1,IRCLKEN=1,IREFSTEN=0 */

  MCG_C2       = 0x01U;         /* MCG_C2: RANGE0=0,HGO0=0,EREFS0=0,IRCS=1 */

  while( 0x04U != (MCG_S & MCG_S_CLKST_MASK)) /* Wait until low internal reference clock is selected as MCG_Lite output */

    {

      nop();

    }

[/code]

Let me reframe the question what possible register could I set wrong or not set that is required that will cause CLKOUT[bus] to give frequencies that make no sense?

[kerryzhou]

Hi Bob Paddock,

      My code is like this :

void LIRC_8M_BUS4M(void)
{
      SIM->CLKDIV1 = 0x00010000u;    /* Set system prescalers */
      MCG->SC = 0x00u;              /* Set SC (internal reference clock divider) */
      MCG->MC = 0x80u;              /* Set MC (high-frequency IRC enable, second LIRC divider) */
      MCG->C1 = 0x42u;              /* Set C1 (clock source selection, int. reference enable etc.) */
      MCG->C2 = 0x01u;              /* Set C2 (ext. and int. reference clock selection) */
      OSC0->CR = 0x00u;            /* Set OSC0_CR (OSCERCLK enable, oscillator capacitor load) */
      while((MCG->S & MCG_S_CLKST_MASK) != 0x04U) {} /* Wait until low internal reference clock is selected as MCG_Lite output */
}
void HIRC_48M_BUS24M(void)
{
      SIM->CLKDIV1 = 0x10000u;    /* Set system prescalers */
      MCG->SC = 0x00u;              /* Set SC (internal reference clock divider) */
      MCG->MC = 0x80u;              /* Set MC (high-frequency IRC enable, second LIRC divider) */
      MCG->C1 = 0x00u;              /* Set C1 (clock source selection, int. reference enable etc.) */
      MCG->C2 = 0x01u;              /* Set C2 (ext. and int. reference clock selection) */
      OSC0->CR = 0x00u;            /* Set OSC0_CR (OSCERCLK enable, oscillator capacitor load) */
      while((MCG->S & MCG_S_CLKST_MASK) != 0x00U) {} /* Wait until low internal reference clock is selected as MCG_Lite output */
}
void CLKOUT(void)
{
      SIM_SCGC5 |= SIM_SCGC5_PORTC_MASK;
      PORTC_PCR3 = PORT_PCR_MUX(5);
      SIM_SOPT2 |= SIM_SOPT2_CLKOUTSEL(2);
}

void HIRC_48M_BUS24M(void): use HIRC 48Mhz as the source for core clock, then core clock is 48Mhz, bus clock is 24Mhz, I can get the 24Mhz from PTC3.

void LIRC_8M_BUS4M(void): use LIRC 8Mhz as the source for core clock, then core clock is 8Mhz, bus clock is 4Mhz,, I can get the 4Mhz from PTC3.

I don't know why you get 48Mhz on your bus when you test on your side, so please create a new barebone code( not choose PE on KDS3.0), just add my function and call function HIRC_48M_BUS24M or LIRC_8M_BUS4M, and test again on your side.

My main function is:

int main(void)
{
    /* Write your code here */
    //LIRC_8M_BUS4M();
    HIRC_48M_BUS24M();
    CLKOUT();
    /* This for loop should be replaced. By default this loop allows a single stepping. */
    for (;;) {
        i++;
    }
    /* Never leave main */
    return 0;
}

Wish it helps you!

If you still have question, please contact me!

Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[bobpaddock]

Your code works well thank you.

My code has been working all along as well just being mislead by the instrument.  Lesson Learned.

"new barebone code( not choose PE on KDS3.0)"

I'm not a fan of KDS or PE.  From the KL27_CLKOUT project above in this thread, KDS produced nearly 30,000 lines of non-blank, non-comment lines of code to do what you did by hand in seven lines of code. 

AlDanial/cloc · GitHub used to count the lines of code.

[mjbcswitzerland]

Bob

I also think that the code generators may be counter-productive in many instances (I have seen them producing large amounts of code to do simple stuff and enabling things (like clocks) that are not required - and subsequently consuming unnecessary power when operating - as well as generating some bugs).

But more importantly: In the embedded development industry my clients say they find it harder and harder to find people (especially students) who can actually solve problems and work efficiently. They are pretty good at things like JavaScript as long as they can use can access libraries to do the low-level work but get lost as soon as they need to atually solve something requiring deeper understanding of how it works below the surface.

The code generators seem to contribute to the new generation of 'script-kiddies' who can do things as long as there is a step by step guide to which switches to set and which buttons to press but then are stuck if it doesn't work as expected or the tools don't happen to support what they need.

I am sure that there would be much less questions about why things don't work when someone has set up a tool to do the work for them and more interesting topics about chip behaviour and techniques to actually do more useful things if this culture had not set in. There are so many threads where people have obviously invested weeks or months of experimenting (changing settings, changing versions, porting between versions etc.) rather than actually understanding what the are doing. I often ask myslef who is paying for their time and also often question the real long-term cost of these "silver-bullet" solutions to the industry.

Regards

Mark

[bobpaddock]

Mark Butcher wrote:

Bob

I also think that the code generators may be counter-productive in many instances (I have seen them producing large amounts of code to do simple stuff and enabling things (like clocks) that are not required - and subsequently consuming unnecessary power when operating - as well as generating some bugs).

But more importantly: In the embedded development industry my clients say they find it harder and harder to find people (especially students) ...

Probably while passing over people with experience because they don't have the *exact* requirements or a meaningless degree (I've had to teach recent CS Grads how to do toggle a LED when they were hired to do Embedded Systems).  HR has become just as Script-Kiddies as well. :-(

Makes me want to go off do a consulting biz. full time for those that can't find people.  Just need to figure out how they would find me?

"get lost as soon as they need to actually solve something requiring deeper understanding of how it works below the surface."  I actually wrote about this in my blog a few years ago:

Software Safety: I'm Scared : ... "We had to switch to Eclipse because all of the people coming to the Embedded World from the Microsoft World did not know how to write their programs without such a tool." ...

Also along those lines are Software Safety: "I Code to Spec"  : "I code to spec. The product and marketing departments write the spec (what little there is); the QA department amends the spec with overly specific test cases. I suggest that the spec is incomplete and won't handle...but I'm told, just code it to spec. I recommend changed, but we don't have time for edge cases. I point out potential problems, but we're unlikely to get any of those. I warn of potential compatibility problems but we don't care. Are you just trying to be difficult? If there's a problem QA will catch it. The project is overdue already, and by the way here are some new requirements that need to make it in, and we can't change the release date because we already promised the stockholders. Why is your code so complicated, my twelve-year-old kid could write this."

and this 'Want Ad':

Software Safety: Wanted: Experianced Embedded System Developer with a Brain
"

EE / Embedded Control Hardware / Software Robot Instrumentation

Needed: One damn hot engineer to finish a robotics project for a very established company in East Pittsburgh Area.

This is a full time position but if you are some hot talented Carnegie Mellon University Robotics student we'll consider part time, as long as you perform and deliver ( unlike the previous degreed graduated CMU student.)

This is a robotics project but the robotics are simple. The little robot is designed to carry instrumentation into a tight, hot crack where no instrumentation has gone before.

Personal Requirement:

1.A brain. 2. A watch 3. A cell phone that you answer 4. Ability to give up girlfriend for being paid professionally. 5. Working with us professionally between the hours of 7am and 7pm, and not the reverse.

Professional Requirements

An excellent understanding and experience with digital circuit design, layout and interfacing. You had darn well better know how to lay out circuit boards and use a hot air rework station to put down SMD if you have to. You need a full understanding of VLSI circuits as well as discrete circuitry. Motor control and instrumentation associated with robotics. Servo Motors, DC Motors, Step motors Motors, Encoders etc..

A phenomenal understanding of the ATMEL AVR type of chipsets and supporting circuits and an excellent command of the C language used for writing code for those chips. You must have a complete mastery of all of the chips features, A/D, I/O, all TX/RX methods, Counter Timers etc..because they are all in use. Reading the articles in Make Magazine do NOT count. Read the first line again; Phenomenal Understanding.

I would hope that you also have a competent ability to write software in a windows environment for the display of the data the robot sends back. Even if its liberty basic / visual basic that is ok, but we'd prefer a full C++ development environment expertise.

You need to have enough understanding of analog electronics to digitize, transmit, store and display the information as well as the use of DC power supplies and supporting instrumentation such as digital storage oscilloscopes. Don't go getting a funny look on your digital experience face if someone asks you about the impedance of your connection.

You must be able to produce and provide documentation. Schematics, illustrations, photo documentation of progress, component lists etc... so they don't have to be extorted from you if you no longer work for us.

You will be signed up with a non-disclosure and confidentiality agreement. You will have a police & background check performed on you as well as drug testing. No criminal history and no history of drug use. Period.

I personally don't care if you are a student, have a BS, MS, or a Ph.D. What we need is ability and capability along with a high desire (even desperation) to work and finish the project. We are looking or talent and I personally was probably doing assembly language programming and building circuits by hand before you were even dumping in your diapers...and I'll be the chief person interviewing you. Come prepared IF you make it to the interview process.

As with any project, there is a point where it ends but of course...what project have you seen that ever ends. A success of a project always moves to improvements and expansion of that project so there is the very very real potential for this to be full time unending employment. Full professional pay, full benefits, vacation time, medical, house, picket fence, 2.5 kids etc.

The work environment is professional in every sense. Nice office, large lab and work area, new Dell Computers for everything, excellent people to work for and just good natured and nice all around. No jag offs trying to make a joke at your expense. We guarantee that.

So you have a choice. The red pill or the blue pill. If you decide the blue pill than please wake up tomorrow and forget all about this. If you decide the red pill then please send back an email with your interest as well as your resume, experience, links to your website with photos /video of accomplishments/project (not your cat) etc...

The USA is basically in a depression and there millions of people out there with extreme talent looking for professional positions so if you want this position you had better make your submittal good.

Thank you, Steve."

[mjbcswitzerland · Accepted solution]

Bob

I don't know what is happening in your case but I can check the IRC8MHz case with bus divide and it is OK, where you wrote that you measured 11.98MHz.

Since this is the default state out of reset it requires only the bus divider and the output to be configured (as you know) so when I use this code I measure 4MHz with a bus divider of 2 and 1MHz with a divider of 8 (and other expected values with dividers or 1..8).

fnClkout(BUS_CLOCK_OUT);                                             // select the bus clock to monitor on CLKOUT
SIM_CLKDIV1 = (((SYSTEM_CLOCK_DIVIDE - 1) << 28) | ((BUS_CLOCK_DIVIDE - 1) << 16)); // set bus clock divides
while (1) {}

The fnClkout() simply selects the source and configures the pin (boiling down to):

SIM_SOPT2 = ((SIM_SOPT2 & ~(SIM_SOPT2_CLKOUTSEL_MASK)) | SIM_SOPT2_CLKOUTSEL_BUS); // select the clock source to be driven to the CLKOUT pin
_CONFIG_PERIPHERAL(C, 3, (PC_3_CLKOUT | PORT_SRE_FAST | PORT_DSE_HIGH)); // configure the CLKOUT pin

Perhaps you should start with this (absolutey simplest case) and monitor the output as you step through the rest of your code to see when it starts "playing up".

What I can state however is that the jitter on the output is quite extreme - if you are measuring with a frequency meter it may well have difficulties locking on to it and could well display overtones or jump about. Measuring with an oscilloscope the frequency can be made out well amoungst the noise/jitter. Hopefully you are not using a frequency meter and being fooled by it....

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

KL27: http://www.utasker.com/kinetis/FRDM-KL27Z.html / http://www.utasker.com/kinetis/Capuccino-KL27/Capuccino-KL27.html

For the complete "out-of-the-box" Kinetis experience and faster time to market

:smileyinfo: Out-of-the-box support for 46 Kinetis boards and 10 IDEs (460 combinations from a single code source with no porting required)

[bobpaddock]

Mark Butcher wrote:

What I can state however is that the jitter on the output is quite extreme - if you are measuring with a frequency meter it may well have difficulties locking on to it and could well display overtones or jump about. Measuring with an oscilloscope the frequency can be made out well amoungst the noise/jitter. Hopefully you are not using a frequency meter and being fooled by it....

I've been using my Rubidium Standard based Frequency Counter for years.  It has never failed me until now.   However I never feed it a single that was so abysmal before either once I looked at it with the scope.  I expect clock signals to be the most pristine of all signals.  How does this part even run with a clock that looks like that? :-(

[mjbcswitzerland]

Bob

I also didn't expect the huge jitter but I wonder whether it is in fact due to some spread spectrum technique being used to cause clock jitter (by deviating its mark-space-ratio but keeping its average frequency stable) in order to improve its EMC performance? This technique is used by ST Micro in their STM32F7xx devices (although I think as part of its PLL) and they also offer a register (RCC spread spectrum clock generation register - RCC_SSCGR) which the user can control to enable/disable it or select its characteristics.

I didn't find any reference to the technique being integrated in the KL27 but it would explain things. It could then be thought of as something positive ;-)

Regards

Mark

[Alice_Yang]

Hello Bob,

Which IDE do you use ?

If you use KDS, about the configuration of clock you can refer to

If you use other IDE , it should also have the same clock configuration files , you can refer to .

Hope it helps

Alice

[bobpaddock]

"Which IDE do you use ?"

None.  The output of KDS and CodeWarrior are not amicable to doing code inspections that I have requirements for.

See:

Firmware Inspections

Let me reframe the question what possible register could I set wrong or not set that is required that will cause CLKOUT[bus] to give frequencies that make no sense?