topic Re: FRDM-KL25Z not responding to VLLSx wakeup sources? in Kinetis Microcontrollers

FRDM-KL25Z not responding to VLLSx wakeup sources?

admin — Wed, 19 Jun 2013 00:50:19 GMT

Hey All,

I've searched the forums and checked various application notes already, yet I'm struggling to exit the VLLSx mode when I am using an external pin as the wakeup source. According to AN4503.pdf:

"For LLS, VLLS3, VLLS2, VLLS1, and VLLS0 the wake-up events are limited to the enabled LLWU wake-up pins and

modules. The pin can be a wake-up source as long as the pin is enabled as a digital source in the Pin Control Register."

I'm doing this yet I fail to exit the VLLSx mode. I have tried the example "Low-power demo" in the kl25sc with not 100% success. I can enter the VLLSx modes no problem. It's only after I attempt to use the associated LLWU pin (say, PTC3 / LLWU7 ) that I have absolutely no response. I have also tried other LLWUx pins without success.

As an example, please let me know if you can:

1) Enter VLLS1 when an I/O pin goes low (say PTD6 / LLWU15 or PTC3 / LLWU7).

2) Exit VLLS1 when that same I/O pin goes high

This request is for the FRDM-KL25Z Rev. D board.

Help is appreciated! Thanks in advance,

Rich

Re: FRDM-KL25Z not responding to VLLSx wakeup sources?

Kan_Li — Wed, 19 Jun 2013 05:41:09 GMT

I think your attempt is polling the pin state from a GPIO like PTD6 / LLWU15 or PTC3 / LLWU7, if the state is low, enable the external input pin with rising edge detection and enter vlls1 mode after that, and when this pin goes high , the rising edge detected on this pin would bring the device out of vlls1 mode.right? Please kindly help to clarify!

Re: FRDM-KL25Z not responding to VLLSx wakeup sources?

chris_brown — Wed, 19 Jun 2013 20:19:58 GMT

Hi Rich,

I have been able to use a falling edge pin wakeup on PTC3 to wakeup from VLLS1. Could you post your LLWU setup code? Maybe your missing one little small thing?

Thanks,

Chris

Re: FRDM-KL25Z not responding to VLLSx wakeup sources?

admin — Mon, 02 Nov 2020 12:59:09 GMT

Ok, so I discovered the two things that were the root of my issue that were not entirely intuitive to me at first, so hopefully this post helps others too. I was originally circling around the LLWU setup code (llwu_configure()) and the NVIC setup code, and all of that code was working fine.

The two things I had to do were:

1) I had to add/enable the following code in my sysinit routine: (This was the most crucial part and must be added *before* initializing the PLL clock)

// Release hold with ACKISO: Only has an effect if recovering from VLLS1, VLLS2, or VLLS3

// if ACKISO is set you must clear ackiso before calling pll_init

// or pll init hangs waiting for OSC to initialize

// if osc enabled in low power modes - enable it first before ack

// if I/O needs to be maintained without glitches enable outputs and modules first before ack.

if (PMC_REGSC & PMC_REGSC_ACKISO_MASK)

PMC_REGSC |= PMC_REGSC_ACKISO_MASK;

2) I had to keep the debug connection active. Otherwise, the only way I could wakeup from VLLSx was through run mode. I.e., stop the debugger, unplug the OpenSDA usb cable and replug it back. To keep the debug connection active, here are the steps I followed, for those who may be interested:

[CodeWarrior]

Go into the debug configuration....
Under the CodeWarrior Download --> [Your Project] FLASH
Next to the [Your Project]_FLASH_OpenSDA connection dropdown box, click Edit...
Click on the Advanced tab
Most likely, the default is "Terminate the debug session(s)". Change it to "Try to reconnect" and specify a desired timeout, if any.

[IAR]

[Not sure how to do this same kind of thing in IAR...]

-Rich

Re: FRDM-KL25Z not responding to VLLSx wakeup sources?

allen_zhan — Wed, 31 Jul 2013 11:20:29 GMT

Thx. Richard.

The post seems to answer what I always want to know about ACKISO.

So if the device is in VLLS mode, then the perihperals and io pads are in a latched state.

We should release this hold state with "Writing one to this bit when it is set releases the IO pads and certain peripherals"(from Reference Manual).

Now the device will return IOs or "certain peripherals" back to normal run mode state.

As the sample code said, perhaps there will cause the hang result when we do pll_init without this release.