LLWU + PORT interrupt

[martindusek]

Hello,

I have configured single pin both to generate interrupt (in PORTx_PCRn register) and to wake MCU (MK20DN512VLL10) from LLS (LLWU_PEn register).

I have enabled both interrupts in NVIC.

When MCU wakes up, will both interrupt handlers (LLW_IRQHandler and PORTx_IRQHandler) be invoked? Or only  LLW_IRQHandler?

When MCU wakes up, are PORTx_IRQHandler and LLW_IRQHandler invoked according to their interrupt priority (higher priority first)?

Does clearing of ISF bit in PORTx_PCRn also clear corresponding bit in LLWU_Fx?

Does clearing bit in LLWU_Fx also clear corresponding ISF bit in PORTx_PCRn?

Best regards

Martin

[philip_drake]

Hi Martin, Fred and any others contributing here.

I'm the guy who wrote the app note AN4503 on low power. Fred, I'm not sure why the KQRUG says the wakeup sequence is not obvious.  It is know and predictable once you work through the details.

Let me say first that I'm updating the app note with some more accurate notes about the use of the interrupt and the LLWU wakeup. It will be out soon, I'm told that this means March 2015.

Note, that although the MCU versions may be different, all of the mode entry and exit sequences have stayed pretty much the same.  Some devices, like some of the KL series parts do not have a pin interrupt for each of the LLWU wakeup pins, so this discussion about using port pin interrupts with LLWU pins does not apply to all LLWU wakeup sources.

It seems this thread has some good questions about this low power exit, so I will let you know what I have experienced and what I have learned, speaking with the MCU low power designers and other apps engineers.

When waking from LLS from a LLWU enabled pin, only the LLWU interrupt is taken.

While in LLS mode, the port interrupt logic is not even powered up. So, when the edge that wakes the MCU from LLS occurs the only logic that sees the edge is in the LLWU module.The port interrupt flag is not set and therefore the port interrupt function will not be called.  I hope that clears up some confusion that I might have caused. My statement in Rev. 1, 11/2012 of AN4503, that said that the ISF of the port pin is cleared with the clearing of the LLWU pin flag is incorrect. Sorry.

If there is a critical edge that you must catch, you need to use a pin that had both functions pin interrupt and LLWU wakeup.  Enable the edge interrupt logic with the PORTx_PCRxx register and the LLWU edge detect logic in the LLEU_PEx registers. Then you will not ever miss an edge.

In RUN, VLPR, WAIT, VLPW, VLPS, or STOP the interrupt for the port pin will be taken. While the MCU is transitioning into LLS and even VLLSx modes, the edge input will cause an interrupt and abort the mode transition.  The Stop Abort Flag will be set in this case will be cleared upon the next low power mode entry if no other interrupt occurs during mode entry. While in LLS the edge will wake the MCU and take the LLWU interrupt vector.

There is no reason that the port interrupt function and the LLWU interrupt function need to be two different functions. One function can handle the edge exception handling.  If the LLWU flag is set clear it, if the PORTx_PCR_ISF flag is set, clear it, do your work and then exit the isr function.

Now things are just a little different when it is a module waking the MCU from LLS.  If using the LPTMR to wake from LLS the LLWU interrupt is taken first.  Clearing the LLWU module flag has no effect and is not needed.  If you do nothing with the LPTMR in the LLWU interrupt function then when exiting the LLWU interrupt the LPTMR interrupt will be taken.  (Exiting one interrupt and entering another is call Tail Chaining and takes fewer cycles that a full exit and entry into the service routine.)  However if you clear the LPTMR flag, read the LPTRM flag back then clear the NVIC_CPIF bit in the NVIC, then the source of the interrupt is cleared and the LPTMR interrupt service routine is not called.

There is a subtle serialization that is mentioned in the sequence above. Please note that it can take nearly 12 cycles for a write to clear the LPTMR flag to complete. There are a few gaskets that the write passes through on its way to the peripheral.   If you write to the flag and then immediately try to exit the interrupt, the flag write will not have had time to complete.  The result will be that the interrupt handler the MCU just left, is re-entered since the flag causing the interrupt is not cleared yet. However, if you write the flag, then read it back, the core will stall the code execution to wait for the write to complete before it issues the read.  This ordered process serializes the sequence of real-time events.  

Another little tidbit of information it took some experimentation to figure out, is that when waking the MCU from VLLSx modes with the RTC_SECONDS interrupt, you need to enable the clock gate to the RTC before the the NVIC clear pending interrupt flag will be cleared.  The reason for this is that the RTC has a handshake that is occuring with the NVIC and trying the clear the NVIC clear pending interrupt flag from the LLWU interrupt function of the RTC_SECONDS interrupt function will not complete if the RTC clock gate is not written.

I'll keep monitoring this thread to see if any of you have any further questions about various mode entry and exits.

Best Regards,

Philip Drake

[mjbcswitzerland]

Hi Philip

Maybe after these details you could just link this thread to your new version of the application note ;-)

It is certainly good to have authoritive feedback.

Did you check out the link µTasker LLWU Support ? It is not aimed at giving the same information but more a practical user's interface guide so I hope that there are no major boo-boos there.

I have also tested various configurations in many different devices and wonder whether you exerienced that fact that waking from LLS with the RTC alarm on the KL25 (maybe others but certainly not KL03 or KL43) wakeup occurs without any flag set in LLWU_F3? It is not a big issue because the LLWU interrupt is called without any flags set anywhere so this source can be "assumed", but it is a difference that can be shown.

What I have been working on recently for KL devices without external RTC clock inputs is utilising LPO for long term alarms with accuracy in and out of low leakage modes. This allows the user to set an alarm in the RTC for say 12:00 on 20th March 2015 (with the limited long term accuracy of the LPO but better than nothing). The device may be moving in and out of LLS or VLLS and waking due to LLWU pin sources etc in the meantime and may be in low leakage mode or running when the alarm finally fires. This requires compensating for lost counts during low leakage modes when the 1s interrupt can't be handled to compensate for the 1/32.768 clock rate - when entering or leaving the low leakage modes, by either wakeup to RUN or via reset.

Using this this compensation strategy it is possible to either alarm via interrupt at the appropriate time/date or via a wakeup out of low leakage power mode with a 'reasonable' accuracy without needing an external oscillator. The technique is overviewed at the link but I expect to be adding more details now that its solution has been (more or less) finalised. In any case, whenever the project is configured for LPO as RTC clock source (lowest power and cheapest solution) the alarm compensation is performed automatically so that it seems that it has a real RTC with 32.768kHz source.

Regards

Mark

Kinetis: µTasker Kinetis support

LLWU: µTasker LLWU Support

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

[Monica]

Hello Martin,

just checking up on this, was the information provided by Paul useful?

Please let us know :smileyhappy:

Best regards,

Monica.

[fredroeber]

I am having troubles with GPIO interrupts when I wake up from LLS mode and have questions very similar to Martin's questions. I am using the MK20DX128VLH5 processor but I assume that it operates similar to the MK20DN512VLL10 Martin asked about with respect to these issues. Here's the thing. A person named Paul supplied an answer to Martin's question. But the answer really isn't quite right. As in my case, Martin asked about exiting LLS mode based on a GPIO change. Paul's answer talks about going through a reset process. This may be true for exit from VLLSx modes but not LLS. For LLS, when the processor receives the wakeup signal the LLWU executes the LLWU wakeup ISR and then returns to the code following the WFI instruction that put the processor to sleep.

Where I get (very) confused is that Freescale provides a "Kinetis Quick Reference User Guide, Rev. 2, 08/2012" document that states in section

5.3.2.4:

"The wakeup sequence is not obvious for some of the modes. For most of the wait and stop modes code execution follows a predictable flow. For LLS mode which requires the LLWU, the LLWU vector is fetched and taken right after the wakeup event. If the wakeup source’s interrupt flag is not cleared by the LLWU interrupt handler, then the next interrupt vector for the wakeup source is taken and the flag in the port or module can be cleared. Code execution then continues with the instruction following the WFI instruction that sent the MCU into the low power mode."

This does happen for module wakeups; both the LLWU and module interrupt handlers run. But I can't get it to happen for GPIO pin wakeups where only the LLWU handler runs. That is contrary to the User guide.

Freescale also provides App Note 4503 on low power operation. Section 9.1 of that document is on exiting low power modes and states:

"The enabled GPIO pins can also function as a pin interrupt to wake the MCU. If the pin is configured as both a pin interrupt and an LLWU wake-up pin, the operation of clearing the LLWU pin flag in the LLWU register clears the corresponding ISF flag bit in the port register. If the wake-up is from LLS mode, clearing the associated LLWU flag will then create an interrupt flag in the Port Control Register."

That's what I would like to happen but it doesn't. So I'm trying to figure out a clean SW design for having an LLS wakeup invoke the interrupt handling code for a GPIO pin transition that caused the wakeup. I can use the NVIC "pending interrupt" registers to set a pending interrupt for the GPIO port that contains the pin that caused the wakeup but I can't find any way to trigger an interrupt that my code can detect for the specific pin that caused the wakeup. And I really want to be able to have a generic LLWU wakeup interrupt handler that doesn't have to replicate all the code that is in my GPIO interrupt handler. And I want the GPIO code to run at the priority set for it and not the priority set for the LLWU interrupt.

Because I have often been tasked with writing/fixing the BSPs for operating systems supporting "safety critical" applications running on many different flavors of Freescale processors I know that "the devil is in the details" and getting things right can be very tricky at times.

I'm really hoping someone can suggest a workable method for handling GPIO pin wakeup events from LLS processor mode. And I would like to know what pieces of the supplied Freescale documentation on this subject is most correct or whether there truly is no way to have a GPIO interrupt handler run for the pin that caused an LLS wakeup.

Thanks in advance for the type of helpful answer I have most always been able to get from the great Freescale team.   Fred

[martindusek]

Yes, it was useful :smileyhappy: Thanks

[Paul_Tian · Accepted solution]

Hi, Martin

Let me explain the process of wakeup from LLSx mode. When MCU is waken up from LLSx mode, it will run reset process directly without run into LLWU ISR. After reset, MCU will run into LLWU ISR to clear LLUW interrupt flag. If at this time, GPIO interrupt generation condition is still matched, GPIO interrupt flag will be set.

Q1: When MCU wakes up, will both interrupt handlers (LLW_IRQHandler and PORTx_IRQHandler) be invoked? Or only  LLW_IRQHandler?

A1: Only LLW_IRQ Handler.

Q2: When MCU wakes up, are PORTx_IRQHandler and LLW_IRQHandler invoked according to their interrupt priority (higher priority first)?

A2: No. LLWU_IRQ is first.

Q3:Does clearing of ISF bit in PORTx_PCRn also clear corresponding bit in LLWU_Fx?

A3: Please reference the process I mentioned. This condition will not happened.

Q4: Does clearing bit in LLWU_Fx also clear corresponding ISF bit in PORTx_PCRn?

A4: Please reference the process I mentioned. This condition will not happened.

Hope my reply can help you.

Paul

[jvasil]

| Q1: When MCU wakes up, will both interrupt handlers (LLW_IRQHandler and PORTx_IRQHandler) be invoked? Or only  LLW_IRQHandler?

| A1: Only LLW_IRQ Handler.

Note that some of the Freescale application notes say that BOTH ISRs will be executed.  However, I cannot confirm or refute this at present.

[mjbcswitzerland]

James

When the processor is set to a low leakage power mode the LLWU is attached (it is isolated in the processor's RUN mode).

This means that if LLWU and GPIO interrupts are enabled on a pin the GPIO interrupt occurs when in RUN mode. Once in low leakage power mode only a LLWU interrupt will occur.

Regards

Mark

Kinetis: µTasker Kinetis support

LLWU: µTasker LLWU Support

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

[jvasil]

Hi Mark,

Here is what AN4503 says:

9.1 Exiting low-power modes
The enabled GPIO pins can also function as a pin interrupt to wake the MCU. If the pin is configured as both a pin interrupt and an LLWU wake-up pin, the operation of clearing the LLWU pin flag in the LLWU register clears the corresponding ISF flag bit in the port register. If the wake-up is from LLS mode, clearing the associated LLWU flag will then create an interrupt flag in the Port Control Register.
    Source: "Power Management for Kinetis and ColdFire+ MCUs". Page 30. Freescale. AN 4503. Rev. 1, 11/2012.

Freescale has also given us a copy of a draft version of a revised/updated AN.  It rewords this section and seems to emphasize that that both ISRs can run:

10.1.1 Pin Interrupt and LLWU Wake-up functionality integration
If the pin is configured as both a pin interrupt and an LLWU wake-up pin, the corresponding ISF flag bit in the port control register may be set and can be cleared in the LLWU. If the ISF flag is set and is not cleared in the LLWU ISR then the port ISR will be taken after the LLWU isr completes.   
    Source: "Power Management for Kinetis MCUs". Page 47. Freescale. AN 4503. DRAFT. Rev. 2, 02/2015.

This AN seems to be saying that if you configure the part just right, then both ISRs will run.  This is NOT quite the same as saying that the port ISR causes an interrupt while the processor is in a low-leakage mode.

Please note that I do not yet have an opinion about what the part actually does--I am only discussing what is said in this application note and app notes--like every other piece of documentation--have been known to have errors in the past!

Cheers,

James

Comments? DavidS or josem.reyes.chaidez

[DavidS]

In summary there are different interrupt domains.  When in VLLSx mode, then only the LLWU enabled sources will generate a Reset event. If the same pins used for LLWU also has ability to generate GPIO interrupt, then if an interrupt occurs prior to executing WFI instruction, then that interrupt will get serviced.

If the pin/signal you choose does support both GPIO interrupt and LLWU source,  you should be good to go for the async mode.

Regards,

David

[mjbcswitzerland]

Hi James

The GPIO interrupt can't wake from LLWU but it is connected to the same pin and so its interrupt may be pending after wakeup due to the LLWU pin (also depends on its configuartion because a LLWU could be on a falling edge but the GPIO interrupt on a rising edge etc.). Whether it is then handled depends on what the LLWU interrupt handler does so you can control it as you wish - you can directly handle pending GPIO interrupts or simply based on the present GPIO state if you like or leave it to be handled by the GPIO handler, or clear it...

The situaltion after a VLLS mode (always exited via RESET) is different because some LLWU modules remain in the isolated mode and have to be first cleared before the non-isolated functions can operate again.

In any case you need to experiment with the processor in question because there are some differences and also you need to check the errata sheet because some LLWU behavior can be unexpected (eg. the ordering of pending interrupts being take is not always as expected).

A general application note is OK as introduction but you need to concentrate on the particular part and your own particular configuration - half an hour with the device is worth more than a week studying an application note, although the basic knowledge from the appliation note will of course help.

For example - I have worked with various devices waking for LLS via the RTC. Some wake with the RTC event flag set and some without the event flag set so detailed handling may need to be adapted accordingly.

Regards

Mark

Kinetis: µTasker Kinetis support

LLWU: µTasker LLWU Support

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