KL02 Looks like it's operating at 32KHz rather than 41MHz. Why?

cancel
Showing results for 
Search instead for 
Did you mean: 

KL02 Looks like it's operating at 32KHz rather than 41MHz. Why?

240 Views
Contributor I

Hi there,

I'm a bit puzzled about what I'm seeing. I've verified that the registers in my KL02Z32 MCU are set up as shown in the diagram below (BTW: love the Config Tool):

pastedImage_1.png

When I put the CPU into a very simple loop which toggles an output, it toggles at a rate of about 4kHz:

  

while(1)
{

         loopcounter++;
         if (loopcounter & 1)
         {
            ledOn(LED_OUTPUT_BASE, 1<<OUTPUT_LED_PIN);
         }
         else
         {
            ledOff(LED_OUTPUT_BASE, 1<<OUTPUT_LED_PIN);
         }

}

I'm guessing that the core is not running at 41MHz. Any suggestions?

Thanks in advance!

Rich

Tags (2)
0 Kudos
4 Replies

6 Views
Contributor I

Good points. Thanks so much for the help!!

Rich

0 Kudos

6 Views
Specialist V

Hi Rich

The KL02 will boot up with a speed of about 22MHz and the setting to get a change to 41.9MHz is to write 0x20 to MCG_C4. Although it is very difficult to read the values in the screen shot I think this is the value that the configuration tools I giving so any problem with speed is likely to be elsewhere.

When I set this to 41MHz and make a loop toggling a port I get about 5MHz output so there is a big difference somewhere.

Although it is not as impressive as a drawing tool I can do this in the uTasker project with these two defines:

#define RUN_FROM_DEFAULT_CLOCK                                       // default mode is FLL Engaged Internal - the 32kHz IRC (31.25..39.0625kHz - factory trimmed to 32.768) is multiplied by FLL factor of 640 to obtain 20.971MHz nominal frequency (20MHz..25MHz)

#define FLL_FACTOR          1280                                  // set highest frequency [1464 gives 47.972MHz] (factors available are 640, 732, 1280, 1464, 1920, 2197, 2560 and 2929)

and its simulator immediately confirms such things:

pastedImage_1.png

Attached is a version for the FRDM-KL02Z board running at this speed - using the command line interface on the VCOM port [115'200Baud] one can also look at registers (in I/O menu) to see how things are set up - eg. to see the MCG block content:

"md 40064000 b 8" which gives

Memory Display
0x40064000     04 80 8a 2c 00 00 10 00  ...,....


Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis KL02/KL03/KL05:
- http://www.utasker.com/kinetis/FRDM-KL02Z.html
- http://www.utasker.com/kinetis/FRDM-KL03Z.html
- http://www.utasker.com/kinetis/FRDM-KL05Z.html


Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

For better, faster, cheaper product developments consider the uTasker developer's version, professional Kinetis support, one-on-one training and complete fast-track project solutions to set you apart from the herd : http://www.utasker.com/support.html

0 Kudos

6 Views
Contributor I

Thanks so much for the help, Mark!

I'm much closer, which is good. While my code and tools are different my registers agree with yours:

pastedImage_1.png

(the 0x81 is different than your 0x8A, but that's the MCG_C3 register, which is a ref clock trim setting, so I don't think that is the difference).

In the course of looking at this I noticed that my cursors of the scope were referencing the wrong channel (oops!:smileyconfused:), so my measurement is 404kHz which is only a factor of 1 off from what you have. That's workable, but it still bothers me a bit that I'm not understanding something here. 

My MCG_S register is 0x10 and the MCG_SC reg is 0x02, though I don't see anything there that would affect that.

The only other thing that I can think of that would affect that is the SIM_CLKDIV1 register:

pastedImage_3.png

Mine shows a n OUTDIV1 setting of 0, which means the core clock is equal to the MCGOUTCLK divided by 1.

I'll keep poking around at it - I don't think I've pulled the code down to pretty much the bare minimum so I don't think there's an interrupt continually going off or something like that....

Is there some other register which may affect the core clock?

Thanks again so much for your time!

Rich

0 Kudos

6 Views
Specialist V

Rich

If your toggle speed is a factor 10 out the clocks are probably Ok but the code used is simply very inefficient and has a high overhead (especially if you don't build it with optimisation enabled).

Use

while ((int)1 != (int)0) {
    FGPIOx_PTOR = (1<<OUTPUT_LED_PIN);

}

where the x is the port reference and you might find it to be considerably faster (even without optimisation).

I think that the library functions that you are using are Ok for first beginner's/learning steps but for performance you will need to check what they are basically doing and then convert to more streamlined code.

You can get optimised port macros from the uTasker open source project if you will need more performance for real developments.

http://www.utasker.com/forum/index.php?topic=1875.msg6798#msg6798
http://www.utasker.com/forum/index.php?topic=1664.msg5917#msg5917

Regards

Mark

0 Kudos