Hi Mark,
Thank you for the information - I think we're talking about the same thing.
In the screen shot below, you can see you get a pop-up when you hover over the "PLL" Module (which seems to incorporate the "PRDIV" and "MCG_C6 (VDIV0) PLL" in the utasker page you referenced).
When I look in the K22 reference manual, I guess I go by "Figure 5-1. Clocking Diagram " in which there is the "PLL" box (same as the MCUXpresso diagram above) which corresponds to nothing I can cross reference in the document BUT, if I look at the utasker diagram, I can see registers MCG_5 (which houses the PRDIV0 "PLL External Reference Divider" bits) and MCG_6 (which houses the VIVO "VC0 Divider" bits which is unfortunately described as a divider when in it actually multiplies the signal coming in).
So, if I'm correctly comprehending what's provided by the reference manual, MCUXpresso and the utasker web page, the PRDIV0 bits divide the clock coming from XTAL0/EXTAL0 to 1 to 1/25th of its frequency, BUT the output must be between 2 MHz and 4 MHz (which means that for an 8 MHz crystal, like what's used on the FRDM-K22F, this can be 2 or 4), and the VDIV0 bits provide a multiplication factor of 24 to 55. The output of the "PLL" module (as NXP calls it) must be between 48 MHz and 120 MHz. Along with this, the "lock" symbol indicates that the timing is only accurate when the "LOCK0" bit is set in the MCG_S register - looking at the SDK code, the LOCK0 bit is polled in "CLOCK_EnablePll0" before it returns, where you would expect it to be.
As I will be using an 8 MHz clock in my K22 based product, like the FRDM-K22F, that means that I want to run in "PEE" mode with the PRDIV0 at 2 and the VDIV0 at 30, like was discussed before.
Anything you can see that is missing here?
Thank you for providing the link to the utasker page - that really helped cement what is happening here.
myke
Hi Mark,
Thank you for the information - I think we're talking about the same thing.
In the screen shot below, you can see you get a pop-up when you hover over the "PLL" Module (which seems to incorporate the "PRDIV" and "MCG_C6 (VDIV0) PLL" in the utasker page you referenced).
When I look in the K22 reference manual, I guess I go by "Figure 5-1. Clocking Diagram " in which there is the "PLL" box (same as the MCUXpresso diagram above) which corresponds to nothing I can cross reference in the document BUT, if I look at the utasker diagram, I can see registers MCG_5 (which houses the PRDIV0 "PLL External Reference Divider" bits) and MCG_6 (which houses the VIVO "VC0 Divider" bits which is unfortunately described as a divider when in it actually multiplies the signal coming in).
So, if I'm correctly comprehending what's provided by the reference manual, MCUXpresso and the utasker web page, the PRDIV0 bits divide the clock coming from XTAL0/EXTAL0 to 1 to 1/25th of its frequency, BUT the output must be between 2 MHz and 4 MHz (which means that for an 8 MHz crystal, like what's used on the FRDM-K22F, this can be 2 or 4), and the VDIV0 bits provide a multiplication factor of 24 to 55. The output of the "PLL" module (as NXP calls it) must be between 48 MHz and 120 MHz. Along with this, the "lock" symbol indicates that the timing is only accurate when the "LOCK0" bit is set in the MCG_S register - looking at the SDK code, the LOCK0 bit is polled in "CLOCK_EnablePll0" before it returns, where you would expect it to be.
As I will be using an 8 MHz clock in my K22 based product, like the FRDM-K22F, that means that I want to run in "PEE" mode with the PRDIV0 at 2 and the VDIV0 at 30, like was discussed before.
Anything you can see that is missing here?
Thank you for providing the link to the utasker page - that really helped cement what is happening here.
myke
Myke
Yes, all looks to match. Note that the divider in the PLL is in the "feedback path" and this has the effect of a multiplier on the output frequency. I think you just need to somehow get the PLL to multiple by 30.
Here is the code that I use for HSRUN at 120MHz on this board and I have written the exact hex values written to the registers as reference:
MCG_C2 = (MCG_C2_FREQ_RANGE | MCG_C2_GAIN_MODE | MCG_C2_EREFS | MCG_C2_LOCRE0); // [0x94] select crystal oscillator and select a suitable range
MCG_C1 = (MCG_C1_CLKS_EXTERN_CLK | MCG_C1_FRDIV_VALUE); // [0x98] switch to external source (the FLL input clock is set to as close to its input range as possible, although this is not absolutely necessary if the FLL will not be used)
_WAIT_REGISTER_FALSE(MCG_S, MCG_S_OSCINIT); // loop until the crystal source has been selected
_WAIT_REGISTER_TRUE(MCG_S, MCG_S_IREFST); // loop until the FLL source is no longer the internal reference clock
while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST_EXTERN_CLK) {} // loop until the external reference clock source is valid
MCG_C5 = ((CLOCK_DIV - 1) | MCG_C5_PLLSTEN0); // [0x21] now move from state FEE to state PBE (or FBE) PLL remains enabled in normal stop modes
MCG_C6 = ((CLOCK_MUL - MCG_C6_VDIV0_LOWEST) | MCG_C6_PLLS); // [0x46] set the PLL multiplication factor
while ((MCG_S & MCG_S_PLLST) == 0) {} // loop until the PLLS clock source becomes valid
while ((MCG_S & MCG_S_LOCK) == 0) {} // loop until PLL locks
SIM_CLKDIV1 = (((SYSTEM_CLOCK_DIVIDE - 1) << 28) | ((BUS_CLOCK_DIVIDE - 1) << 24) | ((FLEX_CLOCK_DIVIDE - 1) << 20) | ((FLASH_CLOCK_DIVIDE - 1) << 16)); // [0x01240000] prepare bus clock divides
SMC_PMCTRL = SMC_PMCTRL_RUNM_HSRUN; // [0x60] set high speed run mode (restrictions apply) so that the clock speeds can be obtained
MCG_C1 = (MCG_C1_CLKS_PLL_FLL | MCG_C1_FRDIV_1024); // [0x28] finally move from PBE to PEE mode - switch to PLL clock
while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST_PLL) {} // loop until the PLL clock is selected
Simulation below showing the frequencies that result.
Attached is a reference binary for board (it has a memory debugger on its VCOM UART connection at 115k so you can also display register values being used).
Probably by comparing the generated code with the above you can find it more or less is equivalent and identify the value needing change, even if it can't be set in the generation tool.
Regards
Mark
[uTasker project developer for Kinetis and i.MX RT]
