KL03Z and low power modes

[enrico]

Hello,

I am studying how uTasker manages low power modes for the KL03Z MCU. My final objective is to bring the MCU to a very low energy state (ideally very low leakage state) and use a low power timer to awake it every once in a while. Does this sound reasonable and feasible with the KL03Z?

Starting from this interesting wiki
http://www.utasker.com/kinetis/LLWU.html
I've learned that uTasker is already switching from WAIT to RUN when there are operations to perform and to STOP when there are no tasks to perform. Is this correct? Does this apply for the KL03 as well or it uses very low power states?


By analyzing the MCU energy consumption, I get an intermitting behavior that confirms what said above. The screenshot below shows the energy and the accumulated energy in time (uJ and s units).
https://www.dropbox.com/s/bmxfjf8nhjm35a3/Screenshot%202015-11-06%2016.23.27.png?dl=0

However, the off times give very low energy consumption (I get zero, which means current is lower than 500nA that is the measuring sensitivity), that does not match the energy consumption of the STOP mode provided in the data sheet. Is it really going to STOP mode? I guess this is performed into fnDoLowPower function, but I can't understand to what state this is going.

Also, the off times are about 0.2s while the on times are about 0.4s. Is this because of the watchdog? I currently have only an SPI transmission task every 4 seconds.

Looking forward to hearing from you.

Best,
Enrico

[mark]

Hi Enrico

If the project define SUPPORT_LOW_POWER is enabled the Kinetis (all types, including KL03) will be in the RUN mode when executing code and in the WAIT mode when there is nothing to do. That is, when no tasks are presently scheduled that need to operate. In the WAIT mode the clock is stopped to the core so that it saves power but peripherals are still operating normally. This mode is immediately exited as soon as any interrupt becomes pending so that execution of the interrupt takes place with no delay. Interrupts usually (eg. the system TICK) cause the uTasker operating system to schedule tasks and the RUN mode continues until again no more work is to be performed so that the WAIT mode can again be entered.

STOP mode is not involved in the above (default) operation since it means that more clocks are stopped and some peripherals may not be able to work, plus it may take some time to recover operation from the stop mode.

When there is no communication with the Kinetis and it is only really handling its TICK interrupt (usually every 50ms) I expect that there will be WAIT mode current consumption most of the time and a short spike in current every 50ms.
Possibly the time resolution of the recording is too low to see the spike behavior accurately(?). I expect RUN current to be > 3mA and WAIT current to be around 1mA.

In the administrator menu the present power mode can be checked "show_lp". The mode is the one that will be used whenever there is no task activity since the processor will, of course, be in the RUN mode when it actually sends the message.
Using "set_lp" lower power modes can be set and the one chosen will be used instead of the WAIT mode. This will reduce the current consumption further but have side-effects due to more clocks being stopped. STOP mode is usually possible, whereby the default is to allow PLLs to remain in operation to avoid long re-start delays. If STOP mode proves OK for a design it can be used as default by calling fnSetLowPowerMode(STOP_MODE) as soon as possible, for example in fnUserHWInit().

With STOP_MODE as default low power mode I expect around 150uA when not operating and spikes of > 3mA.

Even lower power modes can achieve much lower currents but have also greater consequences, such as some peripherals not being operational or loss of some RAM content or requiring to reset to start operating again. These can be considered with regard to each design so that the best compromise can be found. The default power mode can also be modified so that more extreme states can be achieved when it is known that less functionality is required during the operation.

Since I expect the WAIT mode to be used by default I don't expect the very low readings that you have. I would question the accuracy of the measurement at the moment. Note that, for a test, you could set TICK_RESOLUTION to a high value so that, with no communication, you will also have a long period of time to measure the WAIT mode current consumption without any current spikes. If you disable the low power mode you can also measure the RUN mode since it will always be the mode used.

Regards

Mark

[enrico]

Thank you, Mark.

The measuring system can support up to 28mA, and apparently the board is taking up much more that that (between 30 and 40mA). I guess the intermitting behavior is due to exceeding the maximum current. This might be useful to reduce the board power consumption:
http://mcuoneclipse.com/2013/10/20/tutorial-using-the-frdm-kl25z-as-low-power-board/

I will try that and then go back and try different low power modes.

Thanks for your help.

Enrico

[enrico]

Apparently I had a few problems with my previous setup.

1) I was measuring the power consumption of the board by powering the 3.3V pin in J3-4 . However, I was measuring about 30/40mA, which was suspiciously too high.

Turns out that there was some loop between the KL03 board and the FPGA board that I have connected to it. Specifically, the interrupt wire that is going from the FPGA to PTB3 of the kl03 board (as default in nRF24201.c that I used as SPI reference) was actually powering the kl03 board (!?). Now I've changed PTB3 to PTB7, and the problem is gone. Is this a problem with my board?

With this configuration the board gets about 10mA in wait mode.

2) I was measuring the power consumption of the board, not the power consumption of the MCU. Now I am using the J10 jumper, after removing R27 and R32 from the board as in pg 5
http://cache.freescale.com/files/microcontrollers/doc/user_guide/FRDMKL03ZUG.pdf
or in
http://mcuoneclipse.com/2013/10/20/tutorial-using-the-frdm-kl25z-as-low-power-board/

The Freescale guide says R27 is enough. In other Freescale board guides they mention to remove the 0-R if you use a voltmeter or both if you use an ammeter.

Now, I am powering the board via USB or J2-4, and the MCU through J10-2. The measuring device is providing 3V to J10-2 and measuring the current drawn.
Using this setup I get 2.3mA in wait mode and 5.8 in run mode, not too far from this (pg 11)
http://cache.freescale.com/files/32bit/doc/data_sheet/KL03P24M48SF0.pdf?pspll=1

Does this setup sound reasonable to you?

Thanks,
Enrico

PS. FYI, when I comment #define SERIAL_INTERFACE  in config.h, I get a build error in kinetis.c in

Code: [Select]

#if defined KINETIS_KL03
    _LPSCI0_Interrupt,
    #else


[mark]

Hi Enrico

Low power measurements can prove tricky so you do need to be very careful just which currents are involved. As the processor's own current reduces (eg. in very low power modes where it can be under 1uA) the opportunity for false measurements/leakage currents increases dramatically.

Your WAIT and RUN currents are a little higher than I expect but are certainly much better after your various modifications. I think that testing even lower power mode will help you identify whether they are accurate or not since the currents should reduce a lot again - if they don't reduce you need to suspect further current leakage paths.

In order to solve the probem with the KL03's LPUART interrupt when UARTs are disabled you can use the following:

    #if defined SERIAL_INTERFACE
        #if defined KINETIS_KL03
    _LPSCI0_Interrupt,                                                   // LPUART 0
        #else
    _SCI0_Interrupt,                                                     // UART 0
        #endif
    #else
    irq_default,
    #endif

This will place a default handler in the vector table (in Flash for the KL03 - due to the small amount of memory available) when SERIAL_INTERFACE is not used.

Regards

Mark

[enrico]

Thanks for the advice, Mark.

Do you have any reference from where I could start with the lower power modes?

I have started with stop mode, and a simple interrupt doesn't wake up the MCU. I will try with the lptmr module as suggested in
http://www.utasker.com/kinetis/LLWU.html
Is there any example that use this wake up method?

Also, I've enabled #define SUPPORT_LPTMR in app_hw_kinetis, whichs also enabled  #define TICK_USES_LPTMR. By doing this it seems that a simple interrupt works fine to awake the MCU from stop mode. Is there any documentation about this? What is the advantage of using LPTMR as tick?

Thanks!

[mark]

Enrico

The link to LLWU should contain the most important details about using low power modes.
Always try a power cycle between tests to be sure that the new low power mode is accepted.
When the LPTRM is used as Tick it continues running in low power modes - other timers (sometimes including SysTick) are stopped and so the processor can't wake to handle the TICK - the LPTMR is specialyl designed to run in low power modes and so is useful as a time base.

Regards

Mark

[enrico]

Thanks, I will start from that for the LP modes.


In the meanwhile, I tried to lower the clock speed of the MCU while in run or wait mode. I don't need the 48MHz, I would like to go down to 1MHz.

As a first step, I am trying to go down to 8MHz.

In app_hw_kinetis.h I have
 //  #define RUN_FROM_HIRC                                                // clock from internal 48MHz RC clock
  #define RUN_FROM_LIRC                                                // clock from internal 8MHz RC clock

and
  // #define LPUART_IRC48M                                            // if the 48MHz clock is available clock the LPUART from it
      //#define LPUART_OSCERCLK                                          // clock the LPUART from the external clock
         #define LPUART_MCGIRCLK                                          // clock the LPUART from MCGIRCLK (IRC8M/FCRDIV/LIRC_DIV2)

However, when I power the MCU it kind of freeze and I can see the green light getting stuck. I did some debug and it looks like the board is resetting (fnInitHw is called repeatedly). I see some similarity to what you have experienced here https://community.freescale.com/thread/335304

Any idea of what am I doing wrong?


Another interesting aspect is that, If i connect the SPI clk pin of the MCU (master) to ground, than the core start running and the LED blinking (and lower energy consumption because of the reduced clock). If I deactivate the SPI module, then connecting to ground the clk pin does not have any effect.

Thanks,
Enrico

[mark]

Hi Enrico

I have just tested the power consumption on the FRDM-KL03Z using a standard project. This may help to have some references while going into more detail later:
RUN_FROM_HIRC (48Mhz core) with 32kHz RTC oscillator
- RUN mode 6.6mA
- WAIT mode 2.9mA (measured with an ampere meter - average)
- STOP mode 7.7uA (the LED doesn't flash anymore but the UART responds - although missing characters. This is because the STOP mode of the KL03 stops the SYSTICK from operating and so the TICK is missing - if you send a lot of UART input it will still toggle the LED sometimes because the UART interrupt is allowing the system to enter RUN mode for short times)
- VLPR (didn't respond because it is not possible when using IRC48M)
- VLPS 0.1uA and behavior the same as STOP mode
- LLS - same current and behavior as STOP mode since the KL03 doesn't support LLS
- VLLS0 - processor doesn't react any more and current too low for my ampere meter to measure (using a wakeup input it was possible to reset the device)

The KL03 has, in addition VLPW mode and its STOP mode can be futher set to PSTOP1 or PSTOP2 rather than the normal STOP.
This means that I need to adapt the low power menu slightly to remove the ones that are not supported and add the others specifically for this chip) but I think that the overall results are already representative of what is typically expected on the FRDM-KL03Z without any further HW optimisations.

The next step will be to try with different clock speeds to see whether I can identify any restrictions that may still exist. Presently I can't explain a dependency on the operation and your SPI input but maybe it will be possible to identify something in the process.

Regards

Mark

[enrico]

Thanks for the useful information. I will start by reproducing your results. For the RUN and WAIT mode they are not too far from what I've measured.

Few clarifications:
- Are you measuring the MCU energy only through J10?
- When you say RUN_FROM_HIRC (48Mhz core) with 32kHz RTC oscillator, what do you exactly mean?
- How do you go from STOP and VLPS to RUN? Since tick is not operating I guess you are using LLWU, right?

Thanks
Enrico

[mark]

Enrico

I measure current accross J10.

SUPPORT_RTC is enabled, which causes the 32kHz oscillator to be configured (and RTC to operate) - in fact when I disabled this my board didn't start but I didn't look in to why yet.

I have to press the reset button to leave STOP and VLPS modes and get back to RUN - these have no LLWU operation since they are not LLS based modes)
I could switch back in code when a UART interrupt is handled, which causes a schedulre pass (for example) but for general purpose tests the reset is OK.

Mark

[mark]

Enrico

Another way of reducing the core and bus/flash clocks when working with IRC48M is to configured dividers as follows:
    #define SYSTEM_CLOCK_DIVIDE  8                                       // 1..16
    #define BUS_CLOCK_DIVIDE     2                                       // 1..8 (valid for bus/flash and divisor is after the system clock divider)
Without these they defaut to 1 and 2 respectively (48MHz core and 24MHz bus/flash)

With the values above it means that the core clock is 6MHz and the bus/flash clock is 3MHz.

These are my measurements like this (others the same):
RUN 2.0mA
WAIT 1.5mA


Then I selected RUN_FROM_LIRC (defaults to 8MHz core and 4MHz bus/flash) and didn't have problems:
RUN 2.2mA
WAIT 1.6mA

Regards

Mark

[mark]

Enrico

I checked out the (old) link that you had found about difficulties running from the 32kHz clock.
Then I tried it and it ran OK.
I don't know what is different but I do think that the flash configuration options have been changed since then to ensure that the NMI input is disabled and that the internal boot ROM is also not used.

Although the timing accuracy is high, due to the more accurate crystal (compared to the internal RC osciallators) I found that current consumption was fixed at about 1.2mA (RUN and WAIT). This is a lot higher than expected seeing that the clocks are so slow!

Furthermore, the processor is "really" slow - the command line menu takes longer to print out. Also I see that when the menu is being output the complete processing power is used up to handle the UART interrupts (DMA is not supported by the KL03). In fact I need to disable the watchdog to stop it firing during this time.

32kHz crystal operation therefore doesn't really have any great low power advantages.

Regrds

Mark

[mark]

Hi

Update with regard to the problem that I had trying to run with the RTC disabled:

It was due to a work-around for errata 8068 "RTC: fail to enter low power mode if RTC time invalid flag (TIF) is not cleared after POR"

    POWER_UP(6, SIM_SCGC6_RTC);                                          // temporarily enable the RTC module
    RTC_TSR = 0;                                                         // clear the RTC invalid flag with a write of any value to RTC_TSR
    POWER_DOWN(6, SIM_SCGC6_RTC);                                        // power down the RTC again

It was due to optimisation - GCC was removing the POWER_UP and POWER_DOWN around the RTC_TSR = 0; which meant that a hard-fault was being generated when performing the write.
Solution was to declare all SIM_SCGCx registers as volatile so that the compiler never optimies them out.


Whether RTC is running or not doesn't affect RUN and WAIT current consumption, although I need to revise my original measurements at 48MHz core and 24MHz bus/flash a little:
RUN 6.0mA
WAIT 2.5mA

The reason is that I has the 24MHz bus clock output on CLKOUT. The fact that the output is toggling at this speed increases current by around 400uA. Also when the output is touched, or there is a load on it, like an oscilloscope probe, it can rise by another few hundered uA too. Therefore port switching at high speeds should be avoided in order to keep the consumption down, as should capacitive loading of such outputs

Regards

Mark

[enrico]

Hi Mark,

Thanks for your analysis, that really helps!

I've done my homework too, and here are my measurements:
RUN 5.8mA
WAIT 2.3mA
STOP 160uA
VLSP 5uA
VLL0 2.5uA

Except for VLL0 (which should be much lower), my measurements are fairly close to the ones here (from pg 11)
http://cache.freescale.com/files/32bit/doc/data_sheet/KL03P24M48SF0.pdf

Your STOP measurement seems very low instead. Do you have any idea why is that?

I've also reduced the clock to 3MHz and I get RUN around 1.8mA and WAIT around 1.2mA.


I have also some observations about the freezing problem with lower clock. I have the FPGA  board connected to the MCU via SPI. The FPGA is just waiting for the SPI clock from the MCU.
- With low clock frequency, if I power the FPGA before the MCU, the latter freeze in the initialization. After the MCU is initialized (the LED blinks), I can power the FPGA with no problem.
- This initialization time increases substantially when I lower the clock of the MCU.
- The freezing occurs when the MCU clock becomes lower or equal than the FPGA board clock (12MHz)

From these observations, it seems like some of the SPI pins get during initialization some signal from the FPGA board that cause interrupts/resets? Does this make any sense to you?

Thanks,
Enrico