Bug in Clock Config tool for RT1051?

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Bug in Clock Config tool for RT1051?

跳至解决方案
3,239 次查看
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 项奖励
回复
1 解答
3,182 次查看
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

在原帖中查看解决方案

7 回复数
3,183 次查看
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,158 次查看
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 项奖励
回复
3,146 次查看
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,132 次查看
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 项奖励
回复
3,133 次查看
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 项奖励
回复
3,217 次查看
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Grandfather,

I think Reference Manual is right.

 

BR

Alice

0 项奖励
回复
3,214 次查看
Grandfather
Contributor II

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

0 项奖励
回复