View Unexpected Wake-up Source on FRDM-MCXA153

[aberger]

I have configured the FRDM-MCXA153 to go to Deep Sleep mode, and enabled the Rx Edge Interrupt on LPUART2 (so that it serves as the wake-up source). After a variable and random amount of time (typically between 15 s and 50 s) the CPU will unexpectedly wake back up without having received an Rx Edge. This seems to occur if I have the debugger running and CMC_DBGCTL[SOD] = 0 (debug remains enabled when the core sleeps). If I either end the debug session, or set DBGCTL[SOD] = 1 (disable debug), then the CPU remains asleep as desire

So, I'm suspicious that the debugger is causing the unwanted wake from deep sleep. But is there a way to verify this? Following the unwanted wake, I can see that CMC_SRS[WARM] = 1 and CMC_SRS[SW] = 1. However, CMC_SRS[DAP] = 0, which I am surprised to see. Also, CMC_RSTCNT[COUNT] remains unchanged following the sudden wake.

[Alice_Yang]

Hello @aberger 

How about running your project without debug mode. Program it into chip, then run it standalone without debugger and IDE.

BR

Alice

[aberger]

Hi @Alice_Yang ,

If I run without debug mode, the MCU doesn't not unexpectedly wake up. However, it also won't wake up when receiving the Rx Edge on LPUART2. I have this configured as an enabled interrupt, and have LPUART2_IRQn enabled. Maybe this isn't sufficient, and it is necessary to use the WUU?

From Table 89 in Chapter 18 (CMC), it seems that wake from Deep Sleep should be possible from any enabled interrupts via the NVIC (and that the WUU is only used by Power Down and Deep Power Down):

However, Table 10 in Chapter 2 of the Reference Manual implies that the WUU is used for waking from Deep Sleep modes

Furthermore, I see that in the "How to implement low power on MCXA153" demo available on the Application Code Hub, that even Deep Sleep mode uses the WUU. 

Can you clarify whether the WUU is necessary for waking from Deep Sleep?

[aberger]

Some follow-up context and questions:

My goal in using the Deep Sleep mode is to stop all internal clocks, and wake on a UART Rx Edge. (I will actually need to wake from any of the LPUART Rx signals: LPUART0, LPUART1, and LPUART2). Ideally, the wake delay would be short enough that the UART could service the incoming byte that caused the wake up. 

I was able to "wake" on the Rx Edge during debugging with DBGCTL[SOD] = 0 (enable debug during sleep). However, without the debugger attached, the Rx Edge failed to wake the chip. I now realize that the Rx Edge was likely only detected because the core clock remained enabled by the SOD setting.

So, a possibly dumb question: In order to serve as a wake-up source, is it necessary for a module to remain clocked? If so, then it seems I will not be able to achieve my goal of silencing all clocks.

From the Reference Manual, 23.3.3 Deep Sleep mode (pg 670):

Some modules can remain operational with low power asynchronous clock sources and serve as wake-up sources.

So it seems I either need to clock the WUU and use it to wake the unit. (In that case, I don't think a UART Rx edge can be used, as none of the LPUART signals are listed in Table 84, Wakeup Source for WUU inputs). Alternatively, I need to clock a module itself (e.g. clock the LPUART either from an asynchronous clock source or the LPO CLK16K0) if I wish to use it as a wake-up source during low power operation. Is this accurate?

[aberger]

Some further research:

The MCXA153 data sheet does seem to imply that asynchronous edge interrupts are possible on both GPIO and LPUART. See Table 17 in 3.3.2 General switching specifications

I'm assuming that asynchronous means "un-clocked". Is that the case? If so, what is the proper way to ensure that an asynchronous edge on LPUART Rx (or GPIO) can wake the processor from Deep Sleep? Can you point me to example code?

[aberger]

How is the "asynchronous path" chosen as the interrupt source? I cannot find it in the GPIO or PORT config. 

Finally, what is the difference between the 50 ns GPIO pin interrupt pulse width (digital filter disabled, analog filter disabled) - Asynchronous path and the 16 ns GPIO pin interrupt pulse width - Asynchronous path?

[Alice_Yang]

Hello @aberger 

LPUART remains functional during low-power modes, provided CTRL[DOZEEN] is 0 and the LPUART functional clock is enabled.
LPUART can generate an interrupt or DMA request to cause a wake-up from low-power modes.
You can configure LPUART to be disabled in low-power modes, when CTRL[DOZEEN] is 1. In this case, the transmitter and
receiver finish transmitting and receiving the current word.
If LPUART is disabled in low-power modes, it can generate a wake-up via STAT[RXEDGIF] if the receiver detects an active edge. 

LPUART can continue operating when the processor is in Low-Power mode, if an appropriate peripheral clock is available. So which what about the clock source for LPUART on your project.

If still have any issue, how about sharing your project , I help you check on my side. Thanks.

BR

Alice

[aberger]

Based on my reading of the Reference Manual and the Data Sheet, GPIO and LPUART should be able to generate asynchronous (i.e. unclocked) interrupts to wake the processor from Deep Sleep.

I am attaching a minimum project where I have tried to implement the desired operation as described in the original post. Asynchronous wakeup from LPUART and GPIO does not work with the attached project. The project goals and operation are described in the included README.md, including attached scope screenshots showcasing the runtime behavior.

Please let me know if there is further configuration that would get asynchronous wakeup sources to work properly. If this is not possible, the Reference Manual and Data Sheet should be updated to reflect that wakeup is only possible from clocked peripherals.

I have verified that LPUART_STAT[RXEDGIF] is set upon receipt of commands during Run mode.
I have verified that SW3 can generate interrupts during Run mode.

[Alice_Yang]

Hello @aberger 

Asynchronous not means unlocked. It means the peripheral clock not the same with system clock. 

BR

Alice

[aberger]

As stated initially, I would like to wake from Deep Sleep on either an active GPIO edge or LPUART edge.

You have pointed out that "asynchronous" doesn't mean un-clocked, but rather, clocked from a clock source different than the Core/System clock. If that is the case, how do GPIO modules remain clocked during Deep Sleep in order to serve as a wake-up source? Or is it always necessary to use the WUU to wake from Deep Sleep, and route the desired GPIO pin to the WUU (which itself remains clocked by FRO16k)?

Furthermore, how can I achieve wake-up via active edge on an LPUART peripheral that is disabled in low-power modes? The LPUART is not listed as an available WUU input, and yet the manual states:

37.3.7.1 Low-Power Modes

If LPUART is disabled in low-power modes, it can generate a wake-up via STAT[RXEDGIF] if the receiver detects an active edge.

Though disabled (CTRL[DOZEEN] = 1), does the LPUART functional clock remain enabled? Please provide configuration details for accomplishing the above.

[Alice_Yang]

Hello @aberger 

I strongly recommend refer to "power_mode_switch_ii" under SDK demo.

The demo prints the power mode menu through the debug console, where the users can set the MCU to a specific power modes. Users can also select the wake-up source by following the debug console prompts. The purpose of this demo is to show how to switch between different power modes, and how to configure a wake-up source and wakeup the MCU from low power modes. Deep Sleep: Core clock, system clock, and bus clock are all OFF, some modules can remain operational with low power asynchronous clock source(OSC32k or FRO16K which located in VBAT domain) and serve as wake-up sources.

This demo demonstrates 2 wake-up sources: - LPTMR: Located in System power domain, clocked by FRO16K which from VBAT domain.  

When runt the demo, input C enter Deepsleep mode.

Then you can configure LPUART using FRO16k clock source.

BR

Alice

[aberger]

Hi @Alice_Yang 

Yes, I have looked at that demo. I've also taken a look at the dm-low-power-implementation-mcxa153  demo from the Application Code Hub, which implements similar functionality as the power_mode_switch_ii demo. However, both demos show the processor waking from Deep Sleep via the WUU.

Again, is this necessary? Table 89 shows that Deep Sleep is exited via NVIC, and not the WUU. But I have not been able to get this to work.

I have modified power_mode_switch_ii to try to implement both SW3 as a wake source and LPUART2 as a wake source. The attached project includes Git version tracking with 3 branches representing 3 different attempts to get this working:

1. nvicWakeup - attempt to wakeup from Deep Sleep via enabled interrupts: either SW3 falling edge or LPUART2 RX active edge. RESULT: Does not wake from deep sleep on either SW3 falling edge of LPUART2 RX active edge.  
2. lpuart2fro16k - Attach FRO_16k clock to LPUART2 on transition into Deep Sleep to keep module active on an asynchronous running clock. RESULT: Does not wake from deep sleep on either SW3 falling edge of LPUART2 RX active edge. 
3. gpioWuu - routes SW3 (GPIO P1_7) to WUU P9. RESULT: Does wake from deep sleep on SW3 falling edge, but still fails to wake on LPUART2 RX active edge.

A summary of program operation is also included in the attached slide deck.

Even though the Reference Manual states that any enabled interrupts should be able to wake the unit from Deep Sleep, I have only been able to wake via the WUU. If that is the case how can the LPUART ever be a wakeup source? 

Thank you for your patience and your continued support.

[Alice_Yang]

Hello @aberger 

For the Power mode switch demo, I disabled  WUU interrupt , still can wakeup from deep sleep mode. Comment out the code as below:

For you attached project, sorry I haven't find the configuration LPUART as wakeup source. How about send a standalone project that use LPUART as wakeup source.

BR

Alice

[aberger]

Hi @Alice_Yang ,

I see that the WAKETIMER is also clocked by the FRO16K oscillator, which is perhaps why it works as an NVIC wakeup even without enabling a Module Interrupt wake source in the WUU?

I've attached two projects that try to wake from LPUART and GPIO.

nvicWakeup

1. Add IRQHandler for GPIO1 and LPUART2 (lines 120-128)
2. EnableIRQ for GPIO1 (line 159)
3. Modify App_GetWakeupConfig in order to wake via NVIC on GPIO1 or LPUART2 RX Active Edge if the targetMode is Sleep or Deep Sleep (lines 349-372)

lpuart2fro16k

1. Identical to nvicWakeup except switch to FRO16K clock as LPUART2 functional clock when transitioning to Deep Sleep mode (lines 411-414)

In both projects, the MCU cannot wake from deep sleep on either SW3 (GPIO1, pin 7) falling edge or the LPUART2 RX active edge.

Please suggest modifications to use GPIO and LPUART interrupts as a wakeup source from Deep Sleep. 

[Alice_Yang]

Hello @aberger 

In deep sleep mode, if you want to use LPUART as wake up source, must use FRO16k as clock source. This device only supports FRO16 feature of VBAT. 

BR

Alice

[aberger]

Hi @Alice_Yang ,

Yes, I tried to implement exactly that in lpuart2fro16k. I attached the CLK16K_1 to LPUART2 in lines 411-414. But this still doesn't get the processor to wake from Deep Sleep on a received LPUART2 RX edge. Can you point out what I'm doing wrong?

[Alice_Yang]

Hello @aberger 

I will check your new project on my side. Then reply you .asap. Thanks for your patience.

BR

Alice