Setting kCLOCK_PllVideo in SDK_25_12_00_EVK-MIMXRT1064 fsl_clock.c

[choix361]

Here is the code from fsl_clock.c line 1072~1080. SDK version is 25_12_00.

case kCLOCK_PllVideo:
/* PLL output frequency = Fref * (DIV_SELECT + NUM/DENOM). */
divSelect =
(CCM_ANALOG->PLL_VIDEO & CCM_ANALOG_PLL_VIDEO_DIV_SELECT_MASK) >> CCM_ANALOG_PLL_VIDEO_DIV_SELECT_SHIFT;

freqTmp = ((clock_64b_t)freq * ((clock_64b_t)(CCM_ANALOG->PLL_VIDEO_NUM)));
freqTmp /= ((clock_64b_t)(CCM_ANALOG->PLL_VIDEO_DENOM));
freq = freq * divSelect + (uint32_t)freqTmp;

The last line should be freq = freq * (divSelect + (uint32_t)freqTmp); ?

Is this potential bug? Also, when CCM_ANALOG->PLL_VIDEO_DENOM is 0, this does not handle DIV 0 fault.

[Gavin_Jia · Accepted solution]

Hi @choix361 ,

Thanks for your interest in NXP MIMXRT series!

The SDK line is correct. freqTmp is already calculated as Fref * (NUM/DENOM), so the final output should be Fref*DIV_SELECT + Fref*(NUM/DENOM), i.e. freq = freq * divSelect + (uint32_t)freqTmp;. Using freq = freq * (divSelect + (uint32_t)freqTmp) would multiply freq twice and give a wrong result. 

You are right about the divide-by-zero risk: if PLL_VIDEO_DENOM == 0, the current code would divide by zero and there is no guard in this function. In normal use, DENOM should be programmed to a non-zero value by the PLL init/config, but for extra robustness you can add a simple check (or assert) before the division.

Best regards,
Gavin