topic Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report in Kinetis Microcontrollers

Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Sun, 20 Jul 2014 02:36:48 GMT

Hi All

The use of the STOP based low power modes has been investigated for systems that have continuous UART demands (that is, there is one or more UART that can receive at "any time" and the Kinetis SW may be sending data of its own to one or more UART outputs). At the same time the general power consumption needs to be held as low as possible (eg. in a battery operated system).

The VLPS mode was identified as a potentially very good compromise since it achieves low current consumption but allows UARTs to wake the system on any detected activity.

There are a few discussions about using this mode and also some examples eg.:

Re: Re: K60, UART and Low Power Interrupt enabled, but UART not responding to fopen - help!

Re: Waking from VLPS

however these don't actually allow a randomly operating system to achieve the requirement of optimising power by staying in a low power stop mode for as much time as possible but still responding to any data (eg. at 115200 Baud) that can occur at any time (including when moving to the low power state) without risk of loss of data.

Below are notes made during tests of the design and implementation of such a system. Initially the K, KL and KE family low power modes are compared and currents measured and then the task of achieving the operation specifically for the FRDM-K64F as test vehicle is briefly documented.

The result of the study was a system operating on the FRDM-K64F that would automatically utilise either the normal or low power STOP modes but neither corrupt UART transmissions in progress nor lose UART receptions that can wake up the processor from such a mode at any point in time (or "during" the change to the low power mode). Attached is a binary file that can be loaded to the board showing that the LED blinks and the UART command line interface responds identically in any of the modes (showing no indication that low power modes are in use). Connect to the UART0 at 115kBaud via the virtual COM connection and command low power mode changes in the "Administrator" menu (menu 4) whereby "set_lp 0" commands the standard WAIT mode, "set_lp 1" commands the normal STOP mode and "set_lp 3" commands the VLPS mode ("show_lp" shows the modes available and the one that is presently being used - WAIT is the default).

The current measured at J20 shows that that the typical 28mA current (when not utilising any low power modes at 50MHz clock) is reduced to 14.4mA in WAIT mode, to 0.8mA in STOP mode and < 200uA in VLPS mode operation strategies. [The output on J1-2 can be connected to an oscilloscope to monitor the time that the processor is in the RUN mode ('0') and in the chosen low power mode ('1')].

Regards

Mark

This mode of operation (automatically controlled by the low power task and to be extended to various other peripherals with asynchronous wakeup capability) has been added to the uTasker project and is operational on KE, KL and K devices in interrupt or DMA modes (not KE since it don't support DMA) and will be included in the next release. Pilot projects are in the test phase and users with such low power requirements are welcome to join in the pilot scheme.

µTasker Kinetis support

===============================STOP based modes =============================================================

Basis comparison of mode when a simple project flashes and LED based on SYSTICK and controls a command line menu on a UART that allows the low power modes to be changed:

The low power mode is entered whenever there is no system activity (controlled by a low power task) and any interrupt causes the mode to be exited.

FRDM-KE06Z - normal RUN mode 40MHz 14.0mA VDD_KE06Z; with basic low power mode enabled (WAIT) 5.6mA .

With STOP mode enabled 0.4mA measured when commanded (SYSTICK and UART stop operating)

FRDM-KL02Z - normal RUN mode 48MHz 7.5mA. With basic low power mode enabled 3.4mA

With STOP mode enabled 0.2mA (SYSTICK and UART stop operating)

With VLPS mode enabled approx. 0mA (SYSTICK and UART stop operating)

FRDM-K64F - normal RUN mode 120MHz 45mA ; with basic low power mode enabled (WAIT) 26mA.

With STOP mode enabled 0.8mA. (SYSTICK and UART stop operating)

With VLPS mode enabled 0.2mA. (SYSTICK and UART stop operating)

Since some settings are preserved between resets and some registers can only be written once it is generally necessary to perform a power cycle to start testing a different mode of low power operation.

Attempt to achieve full UART operation in low power modes.

- It was found that the PLL stops in any STOP based modes. If MCG_C5_PLLSTEN0 is set in MCG_C5 the PLL continues running in "normal" STOP mode but is still stopped in VLPS.

- It is necessary to allow UART transmissions to terminate before moving to a STOP mode otherwise the transmitter freezes at the point of present transmission (since clocks are stopped). For this reason the STOP mode was blocked when a UART transmission is still in progress; this means that the system is at full power during the transmission but can then utilise STOP or VLPS, etc. without transmission corruption.

- In normal WAIT mode low power mode operation of 24mA is reduced to 2.8mA in normal STOP mode. Using a low power timer as TICK (RTC was provisonally used) further UART transmissions were possible after wake up to full-speed RUN mode, returning each time to the STOP mode after they had completed.

- In VLPS mode the PLL is always out of lock after wakeup so the system clock was 50MHz rather than the original 120MHz. Re-locking the PLL will take a little time during which the UART Baud rate will be incorrect so it may be best to not use the PLL but instead run from an input clock (as in the 50MHz external clock case). Apart from the loss of PLL clock after wakeup the VLPS mode also allowed UART transmission between VLPS/RUN modes with about 200uA current consumption measured.

The PLL relock time was measured to recover form VLPS mode on the FRDM-K64F, normally operating at 120MHz with 50MHz clock source. This was found to be around 400us and shows that recovery can effect peripheral operating frequencies between the wakeup event and full operation., In STOP mode there is no (noticeable) recovery time required if the option to not disable the PLL in normal STOP mode is used.

Tests were repeated using the 50MHz external clock as system clock (16.66MHz flash clock): WAIT mode current 14.5mA; STOP mode current 0.9mA; VLPS < 0.2mA. In this case there is however no PLL recovery time and so it is much more suitable to being woken by peripherals that must immediately be able to receive.

The final step of unrestricted UART operation with automatic low power operation was to allow UART receptions to wake the processor from VLPS. Since the UARTs are not clocked in STOP based modes the edge wakeup on the UART Rx line must be used. This requires its interrupt to be configured before entering the STOP state and using it as a single shot wakeup interrupt since an interrupt on each edge is not desired in normal operation.

It was found that UART input would now wake the processor from the STOP mode without losing an input at 115kBaud. Furthermore, no interrupts were needed to actually be handled since it could be disabled after the wakeup had occurred, before re-enabling processor interrupts.

In STOP based modes the SYSTICK is also frozen and so, to ensure that TICK operation also continued correctly, a low power timer needs to be used. Initially the RTC was used (with fixed 1s) but the low power timer is generally preferred due to much greater flexibility. For this reason an option was added to allow the low power timer to operate as TICK timer, rather than the SYSTICK, which is then left disabled.

The low power timer can be used with various clocks The first test was using the 50MHz external clock, divided by 64 to get a high accuracy 50ms TICK.

- wait mode 14.7mA

- Stop mode 1.6mA

- VLPS 0.9mA

Now the system reacted identically in the STOP based modes since the tick timer was always active but the VLPS current is higher due to the fact that the low power timer is being clocked at a fast rate.

When the low power timer was clocked by the 1kHz low power RC clock (not as accurate as crystal based but adequate for many applications) the results gave optimal VLPS current consumption with normal system behaviour at all times.

- wait mode 14.2mA

- Stop mode 0.8mA

- VLPS < 0.2mA

The result is a system that works unrestricted with regards to the UARTs and automatically moves between the Run and VLPS modes automatically, spending as much time in the VLPS mode (< 0.2mA) as possible. When UART transmission is in progress (also when using DMA) the RUN mode (about 28mA) is held until complete. When in a low power stop mode any edge on the UART reception line immediately causes a change to the RUN mode so that the reception completes and can be handled.

See the following for a discussion of PLL lock time required when exiting the VLPS mode that can be restrictive to UART (or general peripheral) operation:

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

Original Attachment has been moved to: uTaskerV1.4.8_FRDM_K64F_LOW_POWER_UART.bin.zip

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Sun, 20 Jul 2014 22:52:35 GMT

Hi All

I have am update where it looks that 57600 Baud is the limiting case for the unrestricted operation in this exact mode. First the finding and reasoning is shown and then a workaround is suggestedif 115200Baud (or higher) are required.

During testing it was noticed that occasionalls the first reception character waking the processor would be corrupted. It is believed that thsi is due to the power transistion delay between the normal STOP or VLPS modes to the RUN mode. The reasoning for thsi believe is below, based on the fact that test characters of 0x31 always resulted in a bad character of 0x98,

The first reason is that the data sheet specifies max. 4.5us for the power mode transition which would be about half a Baud period at 115kBaud, thus so putting the sampling pretty much on a data edge (sometimes it would be Ok but in the worst case it could sample bits with one bit delay). The data sheets show the worst case transition delay:
The second reason is that I measured the corrupted character as the content of the correct one but shifted by 1 bit, which would confirm that the processor was indeed woken by the falling edge of the start bit but its bit synchronisation is up to 1 bit delayed. See the following for the effect of the delay that I believe is taking place:

Normal case

Worst case transition delay causes a single bit shift to give the error value that was also sometimes seen.

I increased the Flash clock speed from 16.666MHz to 25MHz (it didn’t change the current consumption values that I could measure – 25MHz is the max. possible) and was surprised that the effect actually got worse. The error seems to occur slightly more often and when it does the error character is 0xcc, which would mean that there is a 2 bit shift!!! I can’t explain why the flash speed setting may cause this effect - I didn’t see 1 bit shift errors – either correct or 2 bits…(?) but it does show that the limiting case must be carefully checked when such parameters are modified. With 57600Baud I didn’t get any errors (also a little strange due to the bigger shift)

I am finally thinking that if a system does need to be able to operate at 115kBaud the following may solve this issue:

Connect the RXD line input to a wake up port which is used to wake the processor from the STOP mode rather than the RxD edge.
Add a delay line between this point and the UART Rx input (a 2..3us delay may be reliable with as simple RC circuit assuming that the inputs have hysteresis)
This would give the UART power mode transition an extra 2..3us to complete and probably allow 115kBaud to operate reliably
Higher speeds would need a better (low power) digital delay line (on all UART inputs – ANDed with one wakeup input) but should result in a solution where high Baud rates can still utilise the VLPS mode’s power savings!

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

nurichard — Wed, 23 Jul 2014 12:41:31 GMT

Hi Mark,

I have done something almost identical on K and KL parts and concur with your maximum 57600 baud for the same reason you gave. I ended up always using the FLL with VLPS to get a <4uA current usage at room temp for some KL parts (this is quite sensitive to temperature and be careful not to touch the PCB; the oil from your skin can noticeably increase the current draw).

To have a faster baud rate it is possible to get external UART buffers (I don't know the part numbers; I was told about such things by a H/W engineer when I reported this limitation of my implementation) that are always on but consume very little power and contain a FIFO to help the microprocessor to cope with the data flow with baud rate conversion and control interfacing via GPIO (data available, overflow notification, transmit from FIFO and baud rate configuration). I think these things were first designed when almost all RX FIFOs were small and high data transfer speeds (~1 Mbaud??) were wanted but the SW wouldn't be able keep up during a reception burst. If anyone knows of some part numbers then please post them as they might be useful once again to help with low power mode UARTs!

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

jamesmasamoto — Thu, 31 Dec 2015 01:04:57 GMT

How did you use the "low power timer to operate as TICK timer, rather than the SYSTICK"? I am trying to do this on K24 but could not get it to work.

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

jamesmasamoto — Thu, 31 Dec 2015 01:06:02 GMT

How did you use the "low power timer to operate as TICK timer, rather than the SYSTICK"? I am trying to do this on K24 but could not get it to work.

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Thu, 31 Dec 2015 03:42:09 GMT

Below is the configuration and handling code in the uTasker project (when configured to use LPTMR as Tick).

    POWER_UP(5, SIM_SCGC5_LPTIMER);                                      // ensure that the timer can be accessed
    LPTMR0_CSR = LPTMR_CSR_TCF;                                          // reset the timer and ensure no pending interrupts
    #if defined LPTMR_CLOCK_LPO                                          // define the low power clock speed for calculations
    LPTMR0_PSR = (LPTMR_PSR_PCS_LPO | LPTMR_PSR_PBYP);
    #elif defined LPTMR_CLOCK_INTERNAL_30_40kHz
    MCG_C2 &= ~MCG_C2_IRCS;                                              // select slow internal reference clock
    LPTMR0_PSR = (LPTMR_PSR_PCS_MCGIRCLK; | LPTMR_PSR_PBYP);
    #elif defined LPTMR_CLOCK_INTERNAL_4MHz
    MCG_C2 |= MCG_C2_IRCS;                                               // select fast internal reference clock
    LPTMR0_PSR = (LPTMR_PSR_PCS_MCGIRCLK | LPTMR_PSR_PBYP);
    #elif defined LPTMR_CLOCK_EXTERNAL_32kHz
    LPTMR0_PSR = (LPTMR_PSR_PCS_ERCLK32K | LPTMR_PSR_PBYP);
    #else                                                                // LPTMR_CLOCK_OSCERCLK
    OSC0_CR |= (OSC_CR_ERCLKEN | OSC_CR_EREFSTEN);                       // enable the external reference clock and keep it enabled in stop mode
        #if defined LPTMR_PRESCALE
    LPTMR0_PSR = (LPTMR_PSR_PCS_OSC0ERCLK | ((LPTMR_PRESCALE_VALUE) << LPTMR_PSR_PRESCALE_SHIFT)); // program prescaler
        #else
    LPTMR0_PSR = (LPTMR_PSR_PCS_OSC0ERCLK | LPTMR_PSR_PBYP);
        #endif
    #endif
    fnEnterInterrupt(irq_LPT_ID, LPTMR0_INTERRUPT_PRIORITY, (void (*)(void))_RealTimeInterrupt); // enter interrupt handler
    LPTMR0_CSR |= LPTMR_CSR_TIE;                                         // enable timer interrupt
    LPTMR0_CMR = LPTMR_MS_DELAY(TICK_RESOLUTION);                        // TICK period
    #if defined _WINDOWS
    if (LPTMR0_CMR > 0xffff) {
        _EXCEPTION("LPTMR0_CMR value too large (16 bits)");
    }
    #endif
    LPTMR0_CSR |= LPTMR_CSR_TEN;                                         // enable the low power timer

static __interrupt void _RealTimeInterrupt(void)
{
    LPTMR0_CSR = LPTMR0_CSR;                                             // clear pending interrupt
    uDisable_Interrupt();                                                // ensure tick handler cannot be interrupted
        fnRtmkSystemTick();                                              // operating system tick
    uEnable_Interrupt();
}

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

karthikbandi — Fri, 21 Jul 2017 13:58:07 GMT

Hello,

I want to configure the MKL16Z64 to low power VLPS mode. But in the low power configuration in proessor expert i can see only LLS and VLLSx. Please provide me some info.

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Fri, 21 Jul 2017 22:29:36 GMT

Your question is not that relevant to the thread so it may be best to create a new topic.

But basically if you need to use PE (which I believe is being dropped by NXP) you may have to accept that you can't do everything.

If you can however also program code yourself you should be able to do it with 3 of lines as follows (possibly interpreting the defines suitably):

        SMC_PMPROT |= SMC_PMPROT_AVLP;    // warning - can only be written once!
        SMC_PMCTRL = (SMC_PMCTRL_RUNM_NORMAL | SMC_PMCTRL_STOPM_VLPS | SMC_PMCTRL_LPWUI);
        SYSTEM_CONTROL_REGISTER |= SLEEPDEEP;

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

karthikbandi — Mon, 24 Jul 2017 07:22:58 GMT

Hello,

Thanks for your reply, So can i use LLS mode and use UART0 to wake up the MCU from low power mode. For UART0 i want to use RXD line to wake up the MCU.

Thanks

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Mon, 24 Jul 2017 08:56:31 GMT

The UART can't wake the processor from LLS mode. You can use a LLWU input connected in parallel to cause it to wake but this tends to be slow (to wake and move back to RUN mode with all clocks stabilised) and so the Baud rate would be limited to (very) low speeds.

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

karthikbandi — Mon, 24 Jul 2017 09:03:07 GMT

Hai,

So what i understood is that i can use UART0 to wake the MCU from low power mode only when its in VLPS mode. But how can i configure it, PE doesnot support to configure VLPS mode. I want to use UART0 to wakeup the MCU from lowpower mode. Which low power mode do i need to use and how i can configure it.

Thanks

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Mon, 24 Jul 2017 13:28:59 GMT

See my previous answer for LLS mode setting.

VLPS can be used up to a certain Baud rate, with the UART's starting edge interrupt waking - see previous report.

You can get all code needed in the uTasker Open Source project.

If you need to do it with PE I can't help but you could open a service request or wait until it is added, or do it with a different processor than the one that you are using where it is supported and move the code over to yours.

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

thasin_akhand — Thu, 17 Jan 2019 19:21:12 GMT

Do You need to disable the systick interrupt?

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Thu, 17 Jan 2019 21:45:18 GMT

Hi Thasin

LPTMR and SYSTICK can be used together so if one needs to be disabled or not will depend on the exact application's requirements.

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

thasin_akhand — Fri, 18 Jan 2019 15:51:27 GMT

Hi Mark,

The reason why I ask is I tried to make the tick driven by LPTMR instead of the SysTick because I go to VLPS quite often and the Systick does not work when cpu goes into VLPS mode. Whenever I try to disable the Systick Interrupt. LPTMR does not work? I was wondering if you knew anything about this?

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Sat, 19 Jan 2019 00:21:59 GMT

Hi Thasin

I am sorry but I have never experienced such a difficulty.

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

thasin_akhand — Thu, 24 Jan 2019 20:35:13 GMT

"allow the low power timer to operate as TICK timer, rather than the SYSTICK, which is then left disabled."

How do you disable the SYSTICK?

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

mjbcswitzerland — Thu, 24 Jan 2019 20:57:12 GMT

Hi

If you don't enable the SYSTICK you don't need to disable it...

Regards

Mark

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

thasin_akhand — Thu, 24 Jan 2019 21:44:48 GMT

I don't enable it, but I still see systick still running the interrupt request. xPortSysTickHandler is still running.

Re: Using Kinetis Low Power Stop Modes with unrestricted UART operation - a report

thasin_akhand — Thu, 24 Jan 2019 21:47:51 GMT

Ok I believe this function, xPortStartScheduler,

is starting the systick, we had a systick_config function that was used and then removed, so I was thinking systick should not have been configured, but in xPortStartScheduler, I believe it is driving the systick.