Advice please: Low-Power/Low-Current applications and Kinetis devices

[WindTech]

There doesn't seem to be much guidance on using the Kinetis family devices in low-power applications where the core, and/or some peripherals, must be kept running continuously (maybe at reduced core/system frequency). I expect the information is there "somewhere" in all the hundreds of pages of documentation, but it doesn't appear to be "obvious" (to me).

Maybe someone in this forum, or someone from Freescale, can enlighten us all on how to achieve optimal low-power/low-current operation with Kinetis devices. Are there any "Application Notes" on low-power operation with Kinetis?

Obviously, Kinetis devices can "run" at high speed for "very short periods" and enter "stop" mode "the rest of the time" to to keep average power/current draw very low, but sometimes it is necesasary to keep some clocks/peripherals running continuously which precludes using "stop" modes. "Wait" mode (core/processor stopped but peripherals running) doesn't seem to make a "huge" difference. According to the Chip Errata, VLPR mode (Very Low Power Run) doesn't work in the silicon revision on a lot of TWR eval boards either.

The webpage for the K60 on Freescale's website states "run currents of <200uA/MHz" - How is that figure achieved in practice?

...In the spec sheet for the K60 (document "K60P100M100SF2") it states: 56mA typical at 100MHz core/system clock in "run mode" (with all peripherals off) = 560uA/MHz, and 1.25mA typical at 2MHz in "VLPR" mode (with all peripherals off) = 625uA/MHz

...Both of those figures are much higher than the "<220uA/MHz" headline figure quoted by Freescale.

How can we expect core and/or peripheral power/current draw to vary as the core/system clock is reduced in the various run/wait modes?

Does the "wakeup time" (i.e. transition from "stop" to "run" etc) vary according to the clock/MCG settings?

Does the MCG have to be reconfigured after a "stop"->"run" transition, or do all the clocks restart with the "before stop" frequencies/setup without any intervention?

How long does it take the MCG clock signals (when FLL is used) to stabilise after a "stop"->"run" transition? Is that "stabilisation time" taken care of in the <6uS "wake up times" quoted in the specsheets?

Using a 32.768KHz crystal to generate a RTC clock which can then also be used with the FLL to create higher frequency accurate core/system clocks looks attractive... is that a good option for low-power applications?

What are the "gotchas" in switching the core, system and/or peripheral clock frequencies "on the fly" ?

How does switching clock frequencies and/or using "stop" modes affect MQX? Does MQX include support for the low-power modes of Kinetis?

Am I missing something obvious: Can <220uA/MHz in a "run mode" really be achieved with Kinetis family devices in practical situations?

There are a lot of clocking (and other) options available to us in the Kinetis chips, and a lot of register settings which can be adjusted in different ways - it would seem that MCG setup and choice of clock generation arrangements are critical for best low-power "run" operation, but it isn't clear from the documentation which options are best.

What are Freescale's recommendations for obtaining the low run currents that are suggested by the "headline" <220uA/MHz figure?

[markccrow]

Did you ever get a response to this message?  Did you ever find more explicit documentation for managing low power modes?  I'm in the same boat and struggling horribly to figure out Kinetis 'low power' modes.  Frustrated almost to the point of abandoning this MCU.

Thanks

[philip_drake]

I would love to say that all of your question are easily answered.  You are correct in saying that the “use of the low power modes in an application” is not discussed in a way that makes it easy.  It is not simple.  I have been working with the Kinetis low power modes at primary validation person here at Freescale and I'm learning something new about low power with every question put forward. 

I do encourage you to take a look at the AN4503 that I wrote.  It’s long and does a lot for the mechanics of entering and exiting the low power mode.  What it does not do, is give guidance to the various use cases that the low power modes should be used.

In a recent use case analysis the applications engineers took a K60 100 MHz device and worked to optimize the MCU for the lowest average current, trying to reduce the "Energy under the curve".  I prepare a set of training slides which I'm writing up soon as an application note. 

Question: Does the "wakeup time" (i.e. transition from "stop" to "run" etc) vary according to the clock/MCG settings?

Answer: The recovery time from STOP, VLPS and LLS is a combination of analog delays ( while power supplies are re-engaged) and synchronization and interrupt latency.  For Kinetis K that translates to 2-4 us plus about 12 core clock cycles.   To get he 4 us specified time you will need to operate the MCU in FEI, run the core, bus and flash clock at their maximums.

Question: Does the MCG have to be reconfigured after a "stop"->"run" transition, or do all the clocks restart with the "before stop" frequencies/setup without any intervention?

Answer: Enter in any mode except PEE clock mode and you exit in same clock mode. (Yes this is all covered in the MCG module sections of the reference manual.

If you enter STOP, VLPS or LLS in MCG clock mode PEE you exit the low power mode in PBE, PLL bypassed running off the external clock. If that external clock is 32768 Hz then the wake up time is on the order of 370 us, based on the above rule of thumb. 

Question: Using a 32.768KHz crystal to generate a RTC clock which can then also be used with the FLL to create higher frequency accurate core/system clocks looks attractive... is that a good option for low-power applications?

Answer: This use of the external 32.768 KHz crystal to generate an RTC clock is a very good solution for low-power applications.  When you need to have a USB stack you will need an additional clock for the USB clock.  If the Kinetis device you are using has two oscillators one can be the RTC low frequency clock that can run the system for most of the time.  When the USB cable is plugged in, another high speed crystal is enabled and the PLL should be used to generate the 48 MHz USB clock speeds needed.

Question: What are the "gotchas" in switching the core, system and/or peripheral clock frequencies "on the fly" ?

Answer: The SIMCLKDIV register can be changed without any system gotchas or glitches.  MCG clock mode changes need to follow the MCG state machine steps.  If you want to use VLPR mode you must set up the clock mode prior to VLPR mode entery. The MCG clock mode must be set to either BLPI (Bypass Low Power Internal) running from the 4 MHz Fast IRC.  The flash clock must stay below 1 MHz, so 800 KHz is a good choice.  Or you can use BLPE (Bypass Low Power External). 

Important Note: You cannot change SIMCLKDIV or MCG clock modes while in VLPR!!!!  This will cause a power supply droop that may result in incorrect operation of the MCU. 

Question: Am I missing something obvious: Can <220uA/MHz in a "run mode" really be achieved with Kinetis family devices in practical situations?

Answer: After studying the trends for current over temperature and voltage the 220 ua/MHz in run mode is possible.  Where is it possible is when running at maximum core clock rate, with bus clock and flash clock of no greater than 25 MHz, with the peripherals inactive and the MCU waiting in a tight loop (that is in cache) like  a while 1, Also,  If you can place the code that is executed during a typical wakeup in RAM and you disable the flash until you need it, the same low run currents can be achieved. 

Lots more to come as I get time to write more application notes.

[rodrigosakai]

Hi Philip,

I am trying to run @ VLPR, using external crystal (32768 Hz). Using KL05, Freedom board, codewarrior IDE, debugging yet.

My application is very simple (1 pulse per revolution enconder, max 400 RPM, 2 channels, numeric display). At initialization, I try to use VLPR, and if no user action after 20s, it goes to VLLS0, reseting (LWU), when user push button.

At the datasheet, I found example moving from FEI to BLPE but using 2MHz crystal. (But it should work!)

At the AN4503, you advise to change internal SLOW 32k clock to FAST internal clock (2 MHz). But how is minimun crystal clock, using external reference?

Using debug codewarrior IDE, after write MCG_C1, and wait for MCG_S, debug goes off (can't read registers, run, pause,stop, anything!)

I wounder if it is a very low frequency to use, or if is only a FRDM board limitation, or anything else.

Example:

void sysinit (void)

{

    unsigned char frdiv_val;

    unsigned char temp_reg;

    short i;

        /* Enable all of the port clocks. These have to be enabled to configure

         * pin muxing options, so most code will need all of these on anyway.

         */

        SIM_SCGC5 |= (SIM_SCGC5_PORTA_MASK

                      | SIM_SCGC5_PORTB_MASK

                       );

        if (PMC_REGSC &  PMC_REGSC_ACKISO_MASK)

        PMC_REGSC |= PMC_REGSC_ACKISO_MASK;

       /* Ramp up the system clock */

       /* Set the system dividers */

      SIM_CLKDIV1 = ( 0

                        | SIM_CLKDIV1_OUTDIV1(0)

                        | SIM_CLKDIV1_OUTDIV4(1) );

      // configure the MCG_C2 register

      // the RANGE value is determined by the external frequency. Since the RANGE parameter affects the FRDIV divide value

      // it still needs to be set correctly even if the oscillator is not being used

        temp_reg = MCG_C2;

        temp_reg &= ~(MCG_C2_RANGE0_MASK | MCG_C2_HGO0_MASK | MCG_C2_EREFS0_MASK); // clear fields before writing new values

        temp_reg |= (MCG_C2_RANGE0(0) | (LOW_POWER << MCG_C2_HGO0_SHIFT) | (CLK0_TYPE << MCG_C2_EREFS0_SHIFT));

        MCG_C2 = temp_reg;

      // Select external oscilator and Reference Divider and clear IREFS to start ext osc

      // If IRCLK is required it must be enabled outside of this driver, existing state will be maintained

      // CLKS=2, FRDIV=frdiv_val, IREFS=0, IRCLKEN=0, IREFSTEN=0

        temp_reg = MCG_C1;

        temp_reg &= ~(MCG_C1_CLKS_MASK | MCG_C1_FRDIV_MASK | MCG_C1_IREFS_MASK); // Clear values in these fields

        temp_reg |= (MCG_C1_CLKS(2) | MCG_C1_FRDIV(frdiv_val)); // Set the required CLKS and FRDIV values

        MCG_C1 = temp_reg;

      // if the external oscillator is used need to wait for OSCINIT to set

          for (i = 0 ; i < 10000 ; i++)

          {

            if (MCG_S & MCG_S_OSCINIT0_MASK) break; // jump out early if OSCINIT sets before loop finishes

          }

          if (!(MCG_S & MCG_S_OSCINIT0_MASK)) while(1); // check bit is really set and return with error if not set

      // wait for Reference clock Status bit to clear

        for (i = 0 ; i < 2000 ; i++)

        {

          if (!(MCG_S & MCG_S_IREFST_MASK)) break; // jump out early if IREFST clears before loop finishes

        }

        if (MCG_S & MCG_S_IREFST_MASK) while(1); // check bit is really clear and return with error if not set

      // Wait for clock status bits to show clock source is ext ref clk

        for (i = 0 ; i < 2000 ; i++)

        {

          if (((MCG_S & MCG_S_CLKST_MASK) >> MCG_S_CLKST_SHIFT) == 0x2) break; // jump out early if CLKST shows EXT CLK slected before loop finishes

        }

        if (((MCG_S & MCG_S_CLKST_MASK) >> MCG_S_CLKST_SHIFT) != 0x2) while(1); // check EXT CLK is really selected and return with error if not

      // Now in FBE 

      // It is recommended that the clock monitor is enabled when using an external clock as the clock source/reference.

      // It is enabled here but can be removed if this is not required.

       // MCG_C6 |= MCG_C6_CME0_MASK;

        //MCG_C6 |= MCG_C6_CME0_MASK;

// continue...

Thank you,

Rodrigo

[philip_drake]

Hello Rodrigo,

What you are suggesting, using the external 32 KHz crystal to run the part in BLPE for VLPR is a valid use of the clock and does work.  It has been verified here in the factory.  When you do switch to FBE the debugger will still work.  When you switch to the BLPE mode the debugger becomes disabled.

You have two options.

1) debug you code at a higher frequency(not BLPE mode.) if VLPR is needed then use the BLPI mode for entry into VLPR and set the clock divider so the flash clock is less than 1 MHz.

2) To eliminate the need for the debugger, what I do most often with this type of code development is create the main to show the part initializing at each step and the loop functioning by toggling outputs, outputting a few characters to a low baud rate SCI, light some LED's.  Then reset and or POR the MCU and let it run.  I will want to measure the IDD of the MCU during the code execution to make sure I'm in the right mode.

The clock transitions are a bit tricky.  You are right to consult the MCG clock function description for the clock change sequeces. The state diagram in figure 24-11 must be followed or you may de-stabelize the MCU clock.  You may want to transition from FEI -> FBI -> FBE -> BLPE instead of directly from FEI -> FBE -> BLPE.

1) you need  start the oscillator like you are doing using the appropriate Oscillator settings for a 32 KHz clock.

2) transition to FBI using the fast IRC, (you can debug through this)

3) check OSCINIT to make sure OSC is started

4) transition to FBE using the external crystal

5) transition to BLPE using the external crystal set the LP bit to disable the FLL. (this will disable the debugger.)

Then you are ready to move into VLPR.as show in the AP Note 4503.

Please remember you cannot switch clock modes or SIMCLKDIV values while in VLPR.

You should get great low current results.

Best Regards,

Philip Drake

[rodrigosakai]

Hi Philip,

One more question about this low-power application.

I cannot restore my application after entering VLLS0 mode if a POR event occurs before restoring RUN mode by LLWU.

The application is the same above, except it has no more push button: "1 pulse per revolution enconder with numeric display"

Same MCU: Using KL05, Freedom board, codewarrior IDE, debugging yet.

First of all, I am using the LED Blink example from Freescale.

I am using VLLS0 mode (LLWU active - PTA5 to wakeup reset).

When the user is not using the device, it enters itself in VLLS0 (after 60 seconds with no pulses). When the user starts to use it, it recovery normally, by reset. (First question: is it a "CHIP POR RESET" or a "CHIP RESET" ?). This part is running ok!

When the supply voltage is powered off in normal mode, and after a while, when the supply voltage is restored, the device turns on normally. (In this case, I imagine a "CHIP POR not VLLS", because POR and LVD sources). This part is running ok, also!

But when the supply voltage is powered off in VLLS0 mode, and after a while, when the supply voltage is restored, the device doesn't turns on immediately (or is stopped in somewhere, but debug is stoped in VLLS0 mode, so I cannot check what happened). But when I have a edge at PTA5 at any moment, so the devices turn on again! (It seams a LLWU recovery, but I am not sure.)

(This would be the case when the user is not using the device for a while, and he wants to change a low battery, so, in this case, I will have a power off voltage supply in VLLS0 mode!! The device hasn't any push button to reset itself!)

I would like the device could reset normally after the user changes the battery (any kind of POR reset), so he can check if the device and the battery is ok, even if he is not reading pulses yet.

I tried to use STOPCTRL[PORPO], to enable POR circuit detect in VLLS0 mode, but no success.

LVD doesn't work at VLLS0, but POR should work anyway, right? (At least if POR is enable with PORPO bit). So, in this case, I would have a "POR ONLY" reset, if LVD is off?

I wounder if I have to set any register before clearing ACKISO.

Thank you for helping!

Rodrigo

[philip_drake]

What I suspect is happening with the battery replacement scenario is that the supply current needs of the MCU are so low in VLLS0 that the capacitors providing storage and filtering for the MCU have sufficient charge that the MCU VDD does not go below the re-arm voltage for the POR circuit.  The data sheet indicates that the minimum re-arm voltage when POR is enabled is 0.8 V.  If POR is not armed then LVD is not re-armed and the MCU will wake up as if there was no power disruption, as if the LLWU wakeup is happening.

When the POR is disabled the MCU is expecting the user to provide protection for the low MCU VDD condition with external power management.  If external control is not available and the VDD dropped to around 0.4 V then the MCU may or may not inidicate a POR has occurred.  And the user must be cautious when restoring the MCU VDD because the digital logic that is powered from the VDD directly, could very well be corrupted when VDD is below 0.8 V.

All this to say that care should be taken when turning off the POR circuit while in VLLS0.

I hope this helps.

Philip

[jg_8051]

Any progress on this, Rodrigo?

I'm also interested on low power modes on Kinetis, and have similar questions as the ones you mention here.

[rodrigosakai]

Hi Philip,

thank you for your advises. I will try these options.

Rodrigo

[DarthVader]

Hi,

I've been working in a very low power application using k20 that aims to wake up the uC at most every 10ms do some stuff and then go back to LLS ( I say at most because some times is much less, like 1ms). I'm getting avg power consumptions of less than 100uA although this depends on the peripherals you use when you wake up. When it wakes up it sets the clock at 72Mhz, plays with some peripherals and then goes back to LLS.

I've lost a lot of hours trying to tune k20 to behave like that. One of the secrets is using the 32Khz crystal + FLL as if you use the PLL the ramp up time is around 30ms (much more compared to the near 6us of the FLL).  I virtualized the LPTMR to provide multiple timers and I use the LWU to wake up from LLS.

After that, I keep looking for an answer of most of the questions you point here. For example if your application uses the USB stack, how the usb can be clocked by the FLL? there is a note in the manual that says that FLL does not seem a good solution for USB clocking.

hope this helps.

[J2MEJediMaster · Accepted solution]

Yes. There are app notes on the subject.

AN4447: Low power optimization using MQX

http://cache.freescale.com/files/32bit/doc/app_note/AN4447.pdf

AN4503 : Power Management for Kinetis and ColdFire+ MCUs
http://cache.freescale.com/files/32bit/doc/app_note/AN503.pdf

---Tom