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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Jump to solution
580 Views
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

Labels (2)
Tags (3)
1 Solution
51 Views
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

View solution in original post

2 Replies
51 Views
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 Kudos
52 Views
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

View solution in original post