MKL17Z256VFM4 not entering LLS

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MKL17Z256VFM4 not entering LLS

Jump to solution
1,465 Views
laurenthenault
Contributor III

Hello,

Like the tittle says, I'm using MKL17Z256VFM4 and want to make it enter LLS mode. I want the MCU to wake up from LLS mode through the LPTMR. Also, I am using SDK 1.3.0 if that changes anything.

Here is what I have so far.

Using Init_SMC in processor expert, I enable Low-leakage stop mode. Processor expert looks like this. 

pastedImage_1.png

SMC seems to be initialized correctly, since I am reading this from the SMC registers.

pastedImage_2.png

I've also enabled the LPTMR and tested the interrupts coming from NVIC and it seems to be working fine. Since NVIC is disabled in LLS , I added the LLWU component with processor expert to enable LPTMR0 and link an ISR to LLWU. This means I should wake up from the LSS through an LLWU triggered by the LPTMR0. Here's what the initialization looks like.

pastedImage_3.png

pastedImage_4.png

The LLWU_ME register reads 0x1, which means module 0, corresponding to LPTMR0, is enabled. So the LLWU should be set properly. 

I created a file named LLWU.c to go along the generated LLWU.h and created a function in there called LLWU_IRQHandler that basically does nothing for now but that will eventually be used when waking up from LLS.

Now comes the problem, at some point in the code, I want to jump into LLS. To do so, I write 0x3 to SMC_PMCTRL. 

pastedImage_5.png

The register is indeed changed correctly but the SMC_PMSTAT register never changes. The debug also keeps going through the code normally which is not supposed to happen if the MCU actually made the switch to LLS.

Anybody has an idea of what I might have bypassed that keeps the MCU from switching modes correctly?

Thanks!

Labels (1)
0 Kudos
1 Solution
1,189 Views
mjbcswitzerland
Specialist V

Laurent

You may also be missing setting SLEEPDEEP in the Cortex system control register. Without this set the wfi() command sets the core to WAIT mode and not to a deep sleep mode and so the low leakage operation will not be achieved.

Regards

Mark

View solution in original post

11 Replies
1,189 Views
laurenthenault
Contributor III

Error ended up being that LPTMR0_PSR was not set properly, I was using MCGIRCLK and it is disabled in LLS, switched to either LPO or ERCLK32K and it seems to be working fine for now!

0 Kudos
1,189 Views
mjbcswitzerland
Specialist V

Hi

Have you executed the __WFI(); command to move to low power mode? The PMCTRL value defines the mode to be switched to but doesn't command the switch.

Regards

Mark


Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts

0 Kudos
1,189 Views
laurenthenault
Contributor III

Hello Mark,

Thanks for the quick answer.

I actually didn't do that. Is that command correlated with the SLEEPDEEP set that is mentioned in the reference manual?

I just added this :

pastedImage_1.png

__WFI(); referencing this:

pastedImage_2.png

Does that seem correct?

I am still getting the same behavior. When I step over the __WFI(); line, the debug keeps going normally when I'm expecting it to stop.

Thanks!

EDIT: Just saw I need to do a read of last register before calling WFI, will try that and comment back.

EDIT 2: Still same behavior after a read of SMC_PMCTRL before __WFI();

0 Kudos
1,190 Views
mjbcswitzerland
Specialist V

Laurent

You may also be missing setting SLEEPDEEP in the Cortex system control register. Without this set the wfi() command sets the core to WAIT mode and not to a deep sleep mode and so the low leakage operation will not be achieved.

Regards

Mark

1,189 Views
laurenthenault
Contributor III

This brings the problem of the LLWU handler. Is what I described in the question right as far as setting up the LLWU goes? 

pastedImage_1.png

ETC...

I'm basically only trying to see I reach this but since the debugger is disconnected it's quite difficult to see what is happening.

Is there any other way the LPTMR has to be enabled for the LLWU handler to be called? 

Thank you,

Laurent

0 Kudos
1,189 Views
mjbcswitzerland
Specialist V


Hi

Attached is the low power interface used in the uTasker project (you can get it as open source in case you would like to compare with fully operational low power operation - from http://www.utasker.com/forum/index.php?topic=1721.msg7086#msg7086). See also http://www.utasker.com/kinetis/LLWU.html for a LLWU discussion and some videos on low power modes in that link.

I recommend that you test first using VLPS since that will not disconnect the debugger. You can then have a break point just after the wfi() to verify that it wakes (and then the LLWU module interrupt should be taken).

  • Ensure that you still enable the interrupt source in the NVIC since it will be needed to take the interrupt after waking (although it is not needed to actually wake up).
  • Check that the LPTMR is still enabled in the low leakage mode that you use so that it can wake up with.
  • Disable interrupts before commanding the wfi() and re-enable after the wake-up to ensure no race-state issues.

The snippets generated by the case tools are only only basic starting points which may only be suitable for simple tests of basic operation so you will need to review the overall requirement and carefully fill in the missing details.

Regards

Mark


Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts

0 Kudos
1,189 Views
laurenthenault
Contributor III

Hello Mark,

Thanks for all the help! I'm currently interning and haven't touched embedded much before that so all of this is pretty new to me.

I'm currently setting the device to LLS but not sure if I'm waking up through an LLWU or not. I will probably try to get VLPS to work so I know I have all the pieces set properly and then switch back to LLS and eventually VLLS0 which is my end goal. 

I was wondering if you could confirm the sequence of actions that happen when waking up through LLWU. It's not really clear for me and it makes it pretty difficult to go about debugging.

For example, at what point is LLWU_IRQHandler() entered? The way I see it currently, and it may be completely wrong, is that I enable the LPTMR IRQ in the LLWU settings, I then put the device in LLS. At that point, when the LPTMR IRQ happens, the device will wake up and run the LLWU_IRQHandler code and return to wherever it was after entering LLS.

From reading through one of the links you shared, it seems that the device will automatically go back to RUN mode after a LLWU event so I don't need to worry about that, but if I want anything else to be done specifically after a wake up ( For example turn on a debug Led to confirm the device woke up)  I should do it in the LLWU_IRQHandler.

Thanks!

Laurent

0 Kudos
1,189 Views
mjbcswitzerland
Specialist V

Laurent


If you just turn on the LED after the wfi() you will also see whether it wakes - it then removes any possible issues with the interrupt after wake-up.

As noted, if you use the the code in the link you will see how it is done correctly.

If you are working for a company that requires results you can also request help at the links I gave, which includes fixing your code.

Regards

Mark

0 Kudos
1,189 Views
laurenthenault
Contributor III

When setting up the LLWU, I enable the LPTMR module as a wake up source. Do I have to also enable the LPTMR interrupt itself or do I only need to enable the LLWU interrupt?

Thanks,

Laurent

0 Kudos
1,189 Views
laurenthenault
Contributor III

Right, since the execution will resume after the wfi when the device wakes up. So I guess my understanding isn't too far off.

 I'll check out the code you mentioned and work from there.

Thanks!

Laurent

0 Kudos
1,188 Views
laurenthenault
Contributor III

Hello Mark,

I added 

pastedImage_1.png

Before the __WFI(); command.

The 0xE000ED10 register is now 0x4 which should mean DEEPSLEEP is enabled.

pastedImage_2.png

The debugger is still not disconnected after sending the __WFI(); command.

This probably gets me a lot closer to something working but it's not quite there, got any other idea?

Thanks again!

EDIT : Maybe it does actually go into LLS, my debugger disconnected once I removed breakpoints. Maybe I just didn't reach it yet when stepping through the code.

0 Kudos