Patch RT1166 fsl_clock.h to fix PLL POST_DIV_SEL Constants

[danieldegrasse]

Prerequisites

• I have checked latest main branch and the issue still exists.
• I did not see it is stated as known-issue in release notes.
• No similar GitHub issue is related to this change.
• My code follows the commit guidelines of this project.
• I have performed a self-review of my own code.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.

Describe the pull request

Constants for field POST_DIV_SEL in ARM_PLL_CTRL_REGISTER were
incorrect, fix them.

Type of change:

• Bug fix (non-breaking change which fixes an issue)

[mcuxsusan]

Thanks @danieldegrasse for the contribution, will sync to develop team for review.

[Albort12138]

Hi @danieldegrasse, thanks for your contribution. I wonder if your application uses those constants? Have you tested it or measured the frequency of ARM_PLL?
From our designer's information, in RT1160 ARM_PLL[POST_DIV_SEL] shrinks to 1bit(0:div8, 1:div4) and another bit is reserved. So I think if set post divider to some unsupported value, the frequency of ARM_PLL is inaccurate.

[danieldegrasse]

@Albort12138 I have been using the div 4 constant in my application, so the change does not affect it. I just tested the frequency using an LED blinking example, and it appears that setting POST_DIV_SEL to 0 results in a frequency of 300MHz on the CM7 core. I based my changes off of the RT1160 reference manual, so the section for POST_DIV_SEL likely needs to be updated to reflect this change. In addition, the CLOCK_GetRootClockFreq function returns the incorrect value of 1200MHz when called with POST_DIV_SEL set to 0.

[danieldegrasse]

Closing this PR, as the issue appears to be one with the reference manual and CLOCK_GetRootClockFreq function, not with the header file itself

[danieldegrasse]

@Albort12138 Just checking, are there any actions needed on my end to get the RT1160 reference manual updated, or will your team handle it?

[Albort12138]

@danieldegrasse I have reported this issue to doc team.