KL24z Wake up from VLLS3

[mikeconover]

I am able to put the KL24Z processor into deep sleep with no problems. However, I am having trouble waking up from deep sleep. I am trying to use the low power timer to wake up every minute from deep sleep. Below is my code to get into VLLS3. How do you wakeup from deep sleep???

SMC_PMPROT = SMC_PMPROT_AVLLS_MASK;

SMC_PMCTRL &= ~SMC_PMCTRL_STOPM_MASK ;

SMC_PMCTRL |= SMC_PMCTRL_STOPM(0x4) ;

SMC_STOPCTRL = SMC_STOPCTRL_VLLSM(3);

SCB_SCR |= SCB_SCR_SLEEPDEEP_MASK;

asm("WFI");

Thanks a lot,

Mike

[mikeconover]

Yasuhiko,

Were you able to get yours working?? I am still not able to get the processor to reset after coming out of VLLS3. :smileysad:

-Mike

[yasuhikokoumoto]

Hi Mike,

my program is working on the KL25 Sample Code (KL25_SC.exe) provided from Freescale with IAR EWARM. It is a baremetal environment. I guess the reason why you could not get reset would be that the processor had not entered VLLS3 mode. The scenario would be the LLWU interrupt was pending, then WFI instruction would be skipped (i.e. not entering VLLSx mode).  I put the following codes before entering the VLLS3 mode. They might be a little redundant.

while (LLWU_F3 & LLWU_F3_MWUF0_MASK) {// Until clearing LPTMR wakeup request
    SIM_SCGC5 |= SIM_SCGC5_LPTMR_MASK;  
    LPTMR0_PSR = ( LPTMR_PSR_PRESCALE(0) // 0000 is div 2
                | LPTMR_PSR_PBYP_MASK  // LPO feeds directly to LPT
                | LPTMR_PSR_PCS(LPTMR_USE_LPOCLK)) ; // use the choice of clock
    LPTMR0_CMR = LPTMR_CMR_COMPARE(1000);  //Set compare value (100ms)
    LPTMR0_CSR =(  LPTMR_CSR_TCF_MASK  // Clear any pending interrupt
                | LPTMR_CSR_TIE_MASK  // LPT interrupt enabled
                | LPTMR_CSR_TPS(0)    //TMR pin select
                |!LPTMR_CSR_TPP_MASK  //TMR Pin polarity
                |!LPTMR_CSR_TFC_MASK  // Timer Free running counter is reset 
                                        //  whenever TMR counter equals compare
                |!LPTMR_CSR_TMS_MASK  //LPTMR0 as Timer
                );
    enable_irq(LLWU_irq_no);//Clear pending LLWU interrupt
}

Does it help you?

Best regards,

Yasuhiko Koumoto.

[mjbcswitzerland]

Mike

As long as you have set the VLLS3 power mode with a LLWU module enabled as wakeup source the processor MUST reset.

Since you measure an increased current it is probable that this is also the case.

However it is also possible that the processor's reset handler, startup code or various other peripheral handlers make a mistake after the wakeup (it is not identical to a power-cycle/system reset), causing the code to hang. Unfortunately the debugger is disabled when the LLS mode becomes active and is usually no longer useable after the reset until the processor is power-cycled (there are some special controls for the debugger to aid in overcoming this but I don't know whether they are implemented/supported in the tools being used and I personally avoid the debugger in such situations).

One problem that I see with the PE solutions is that they are "isolated" solutions and may not necessarily work when put together in complete systems. The individual parts that you are using may do what is written on the box but put together they could create a mash-up of isolated parts that get in each others way or can be a mess at a system design level. This means that in this particular case you may find that the overall system design is the issue because in fact VLLS3 mode and recovery is very simple and involves no more than a handfull of lines of code to manage.

If you are developing for professional reasons and not just hobby where time is not an issue (and no one is paying for it) I can offer a complete solution, or take on a small contracting job to solve your issues. Otherwise I suggest that you step back and implement the VLLS3 operation first on a very small project without other potentially influencing factors until you are happy that you understand the behavior fully and can visualise what may be happening (especially after a reset wakeup without debugger support) and then possibly add parts of the full project back until you find an influence on this behavior.

A couple of final tips:

- when beginning testing, always start with a power cycle to avoid any state-retention that can occur across SW resets after using low power modes
- check the way that your system is disabling interrupts - I have found that using the "CPSID if" instruction rather than "CPSID i" messes up the Kinetis low power operation so I avoid the compiler intrinsics that may use the first version.

Regards

Mark

Kinetis: µTasker Kinetis support

KL25: µTasker Kinetis FRDM-KL25Z support / µTasker Kinetis TWR-KL25Z48M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[mjbcswitzerland]

Hi Yiasuhiko

The NVIC is disabled in VLLS modes and so is not involved, therefore its mask state is not important. Sources only need to be enabled/cleared in the LLWU module (for pins) or in the LLWU peripheral (LPTMR, CMP, RTC etc.)

"The isolated peripherals and I/Os are then acknowledged in the power management controller so that they are released back to their RUN modes. "

The "then" means "after seeing that the wakeup was due to LLWU the isolation is release by subsequently..."

Practically it is not important to actually check the source if it is to always be cleared since the clearing mechanism simple doesn't do anything in the normal Reset case.

Regards

Mark

Kinetis: µTasker Kinetis support

KL25: µTasker Kinetis FRDM-KL25Z support / µTasker Kinetis TWR-KL25Z48M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[mjbcswitzerland]

Mike

When the LPTMR0 expires it causes a reset and so there is no interrupt routine needed.

Regards

Mark

Kinetis: µTasker Kinetis support

KL25: µTasker Kinetis FRDM-KL25Z support / µTasker Kinetis TWR-KL25Z48M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[mjbcswitzerland]

Mike

The only exit possibility from VLLSx is via a reset. The reset can be due to the RESET input or due to a LLWU source - either a LLWU pin or a LLWU module (such as the low power timer that you refer to).

This means that if you don't just want the reset pin as wakeup source you need to program the LLWU source as is the case when waking from LLS.

When waking from VLLS3 via a wakeup source this can be detected by the RCM_SRS0_WAKEUP bit in RCM_SRS0. Since the LLWU module state is held during a VLLS3 wakeup (via reset) the wakeup source (a pin or a module) is still pending in the LLWU module itself so you know what the source was and can react differently if you like.

Beware that some peripherals and I/Os are isolated from the normal RUN mode after such a wakeup and these need to be set back to their normal mode by acknowledging the isolation bit PMC_REGSC_ACKISO in PMC_REGSC (potentially after clearing any details, settings in the peripherals beforehand if needed).

The MQX application is an "example" and it presumably does the simplest thing and that is to behave as if it were a regular reset. This may be valid behavior in many projects too since, depending on the exact VLLSx mode that was woken from, most things need to be re-initialised again. However, as noted previously, the reason for teeh wake up can be determined and so can also control further execution details. [eg. if it was due to the low power timer you may want the system to perform some initialisation and sleep again, whereas if it were a 'full' reset or power up you may want to also perform additional actions such as initialising external devices, etc.].

There is further information about the LLS and VLLSx mode differences and use of the wakeup modules at µTasker LLWU Support

Regards

Mark

Kinetis: µTasker Kinetis support

KL25: µTasker Kinetis FRDM-KL25Z support / µTasker Kinetis TWR-KL25Z48M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[mikeconover]

Mark,

Thanks a lot for your reply. So, when you say the only exit for VLLSx is via a reset, that means the processor gets reset and all my variables are lost?

-Mike 

[mjbcswitzerland]

Mike

VLLS3 retains RAM content so the variables are not lost unless you actively reinitialise (overwrite) them.

You can therefore recognise that the processor has exited from low leakage power mode and recover such information.

What is more complicate is to continue from the original processor context since it means that most peripherals need to be reinitialised and the original processor context would need to be saved before entering VLLS3 mode and also be restored. It is possible but I don't think that this is the aim of the low power mode, but instead to be able to perform a minimal recovery of specific information and then basically re-initialise

Regards

Mark

Kinetis: µTasker Kinetis support

KL25: µTasker Kinetis FRDM-KL25Z support / µTasker Kinetis TWR-KL25Z48M support

For the complete "out-of-the-box" Kinetis experience and faster time to market