Question about recovery time from VLPS mode (or stop mode when PLL is stopped) - K and KL parts

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Question about recovery time from VLPS mode (or stop mode when PLL is stopped) - K and KL parts

ソリューションへジャンプ
1,593件の閲覧回数
mjbcswitzerland
Specialist V

Hi All

Comparing normal STOP mode and very low power STOP mode it is possible to reduce current consumption by a factor of 10..100.

In normal STOP mode the PLL can however (optionally) continue to run and so there is no recovery time after returning to RUN mode (waiting for the PLL to lock again).

In VLPS mode the PLL is always stopped (the MCG is set back to PEE mode) so the first thing that needs to be done (when not running without PLL) is to reconfigure and wait for it to lock again so that the clock frequencies are correct again.

I am wondering about the effect of this when being woked by peripherals - like UART - where the baud rate is not correct during this period. Is the recommendation to avoid using the PLL in such cases or can this procedure be kept short enough that no disruption actually takes place?

Regards

Mark

ラベル(2)
タグ(3)
1 解決策
1,064件の閲覧回数
adriancano
NXP Employee
NXP Employee

Hi,

I agree with the conditions you are suggesting, since the PLL has a Lock time and to operate peripheral using the PLL as the source clock for them will be dependent to the Lock detection time. This Lock detection time is dependent to the PLL reference frequency range and according to the reference manual it is:

lock detector detection time.png

The fpll_ref is the PLL reference frequency range and it can be min. 2.0 MHz and max. 4MHz; with this we can calculate the range of the Lock detection time that will be:

tpll.png

at 2 MHz:

at_2MHz.png

at 4 MHz:

at_4MHz.png

If the purpose is to optimize our application then we see that the lock detection time is quite high and the suggested conditions by Mark are suitable for this.

Best Regards,

Adrian

元の投稿で解決策を見る

2 返答(返信)
1,064件の閲覧回数
mjbcswitzerland
Specialist V

Hi All

After doing some additional work and measuring the PLL recovery time to be around 400us I decided that the best strategy is to not use the PLL, thus avoiding the peripheral operating at an incorrect speed until the final frequency becomes available (and also to avoid possible receive overruns during that time).

Possibly, if the system speed needs to be higher, some peripheral clock settings could be dynamically changed to suit the intermediate clock, an interrupt enabled when the PLL has locked, and the system allowed to run at the intermediate speed. The PLL interrupt could then dynamically change all peripherals clock settings again and continue but there may be peripherals that need to be stopped to change clock settings so this may not be workable generally.

Regards

Mark

0 件の賞賛
返信
1,065件の閲覧回数
adriancano
NXP Employee
NXP Employee

Hi,

I agree with the conditions you are suggesting, since the PLL has a Lock time and to operate peripheral using the PLL as the source clock for them will be dependent to the Lock detection time. This Lock detection time is dependent to the PLL reference frequency range and according to the reference manual it is:

lock detector detection time.png

The fpll_ref is the PLL reference frequency range and it can be min. 2.0 MHz and max. 4MHz; with this we can calculate the range of the Lock detection time that will be:

tpll.png

at 2 MHz:

at_2MHz.png

at 4 MHz:

at_4MHz.png

If the purpose is to optimize our application then we see that the lock detection time is quite high and the suggested conditions by Mark are suitable for this.

Best Regards,

Adrian