AnsweredAssumed Answered

Round-off error in PLL frequency calculation

Question asked by Satish Acharya on Jul 3, 2019
Latest reply on Jul 8, 2019 by Robin_Shen



In MK60DN256VLL10, I'm using external 50MHz clock in PEE mode with divide by 13 and multiply by 26 to obtain 100MHz System clock and Core clock. I couldn't find another way to get 100MHz.


Issue is Kinetis SDK code generates frequency as 99,999,978 instead of 100,000,000 which causes problems in FTM functionality.


I think the real issue is in fsl_clock.c,

uint32_t CLOCK_GetPll0Freq(void)
uint32_t mcgpll0clk;

/* If PLL0 is not enabled, return 0. */
if (!(MCG->S & MCG_S_LOCK0_MASK))
return 0U;

mcgpll0clk = CLOCK_GetPll0RefFreq();

* Please call CLOCK_SetXtal0Freq base on board setting before using OSC0 clock.
* Please call CLOCK_SetXtal1Freq base on board setting before using OSC1 clock.


return mcgpll0clk;

CLOCK_GetPll0RefFreq() sets mcgpll0clk to 50,000,000 which is correct. After we divide by 13 and multiply by 26, expectation is mcgpll0clk will be set to 100,000,000. Instead, it gets set to 99,999,978. This rounding off error creates problem elsewhere. For instance, in fsl_ftm.c,

switch (mode)
case kFTM_EdgeAlignedPwm:
case kFTM_CombinedPwm:
mod = (ftmClock / pwmFreq_Hz) - 1;

Here, I set pwmFreq_Hz to 25MHz and expectation is ftmClock = 50MHz so that mod is 1. Since ftmClock gets set to half of 99,999,978, mod gets set to 0 instead of 1 and it breaks FTM functionality.


For now, I have hacked the code and restructured it so that 26 gets divided by 13 first and the result is then multiplied to mcgpll0clk to get clean 100MHz. I'm not sure how the PLL is designed in hardware and if this change accurately models the hardware.


Please let me know if there is an alternate way to avoid rounding off error or fix the code in the next release.