Bug in Clock Config tool for RT1051?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bug in Clock Config tool for RT1051?

Jump to solution
3,241 Views
Grandfather
Contributor II

Using the Clocks Diagram provided by the Clocks configuration tool the range for PLL2's (SYS PLL) NUM and DENOM fields is limited to 0 - 60000.

Section 14.8.6 of IMXRT1050RM.pdf (the i.MX RT1050 Processor Reference Manual) suggests CCM_ANALOG_PLL_SYS_NUM is a signed 30 bit value whose absolute value must be less than CCM_ANALOG_PLL_SYS_DENOM (an unsigned 30 bit number).

Am I correct in assuming that the clock tool's NUM and DENOM values are the values used for these two configuration fields? If that assumption is correct then it seems most likely that the clock tool isn't handling validation correctly and incorrectly documents the allowed values for these parameters.

I can get around the configuration issue by changing the register values after clock initialisation or accept the much courser clock control imposed by the clock tool. For my application the latter option is not appealing.

So the question is: is the reference manual correct or is the clock tool correct?

0 Kudos
Reply
1 Solution
3,184 Views
marek_neuzil
NXP Employee
NXP Employee

Hello,

I know about the limitation of the Clocks tool. Fractional PLLs of the i.MX RT105x support up to 30 bits that give resolution 0.022 Hz that we cannot use in the Clocks tool. Such a precise PLL calculation will use a lot of CPU time of computer (up to hours) in the Clocks tool engine. We have used the recommended values for i.MX that give resolution 400 Hz (accuracy 0.000076% of the output frequency). In this case the fractional PLL calculation time (of the Clocks tool engine) is in milliseconds.

Do you need higher resolution for your application? Could you provide details of your use case, please?

 

Best Regards,

Marek Neuzil

View solution in original post

7 Replies
3,185 Views
marek_neuzil
NXP Employee
NXP Employee

Hello,

I know about the limitation of the Clocks tool. Fractional PLLs of the i.MX RT105x support up to 30 bits that give resolution 0.022 Hz that we cannot use in the Clocks tool. Such a precise PLL calculation will use a lot of CPU time of computer (up to hours) in the Clocks tool engine. We have used the recommended values for i.MX that give resolution 400 Hz (accuracy 0.000076% of the output frequency). In this case the fractional PLL calculation time (of the Clocks tool engine) is in milliseconds.

Do you need higher resolution for your application? Could you provide details of your use case, please?

 

Best Regards,

Marek Neuzil

3,160 Views
Grandfather
Contributor II

Hi Marek,

thanks for a great answer.

Is it not possible to allow full precision for user provided configuration values? I realize that calculating an optimal ratio to achieve a target output frequency can be computationally intensive, but that is not an issue for user provided values. Maybe perform the frequency calculation with limited precision as is done at present, but allow full precision user provided values?

If it is not practical to allow full precision user provided values it would be nice if the clock tool could message the problem in some way, perhaps a hint in the "Computation failed for element" error? Maybe "Computation failed: allowed PLL resolution exceeded" along with discoverable help to explain the issue.

Our use case is phase locking timers and various other clock based I/O to an external time reference. We would most likely set DENOM to a fixed large value and adjust NUM to fine tune the output clock frequency. We are not setting an initial high precision clock frequency. However we do need to use the full 30 bit precision when the system is running to dynamically control the clock frequency in a firmware PLL.

0 Kudos
Reply
3,148 Views
marek_neuzil
NXP Employee
NXP Employee

Hello,

Thank you for the provided use case of the fractional PLL. I have created a ticket for improvement of the fractional PLLs support for the i.MX RT10xx MCUs (MCUCM-11303).

We will implement an improvement of the fractional PLL  to provide full range of the NUM and DENOM values and automatic calculation of these values based on current (limited) precision.

Do you require to provide a hot fix package for resolving this issue on your local data? 

Best Regards,

Marek Neuzil

3,134 Views
Grandfather
Contributor II

Your IT people may be interested to know that the bug tracking link you gave returns a secure connection failure:

Secure Connection Failed

An error occurred during a connection to jira.sw.nxp.com. SSL peer was unable to negotiate an acceptable set of security parameters.

Error code: SSL_ERROR_HANDSHAKE_FAILURE_ALERT

I am using Firefox 104.0.2 (64-bit) on Windows 10.

0 Kudos
Reply
3,135 Views
Grandfather
Contributor II

Hi Marek,

thanks for a great follow up to have this problem tidied up.

No, I don't need an update urgently. We are just setting an initial value in any case and that value isn't very important. We would need to update the values shortly after the system starts in any case.

Thank you again for your great support.

Cheers,

Peter

0 Kudos
Reply
3,219 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Grandfather,

I think Reference Manual is right.

 

BR

Alice

0 Kudos
Reply
3,216 Views
Grandfather
Contributor II

Should a bug be raised for the clock configuration tool? If so, how?

0 Kudos
Reply