topic Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F in Kinetis Microcontrollers

UART0 does not respond after waking up from STOP mode on Kinetis K64F

germanrivera — Mon, 28 Aug 2017 19:50:29 GMT

Waking up after setting Sleepdeep and executing a WFI will leave UART0 unresponsive.
Is there anything explicit that needs to be done to make UART0 usable again?

Thanks,

German

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

mjbcswitzerland — Mon, 28 Aug 2017 23:04:58 GMT

Hi German

The following report may help:
https://community.nxp.com/message/421247

There are binary files for the FRDM-K64F here which include low power modes for checking the UART wakeup response: http://www.utasker.com/kinetis/FRDM-K64F.html

Regards

Mark

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

germanrivera — Mon, 28 Aug 2017 23:56:56 GMT

Hi Mark,

Thanks for your reply. I had seen that post before, but it does not explain

something needs to be done after wake up to make the UART and Systick

work again. It says that in STOP mode the UART and Systick will stop

working, but it does not say how you make them work again after going back

to RUN mode. I don't need to use the UART or Systick as "wake up sources"

to trigger the transition from STOP mode back to RUN mode. I'm using a GPIO

pin interrupt as the wake up source and that is working. My problem is how

make the UART and Systick work again after waking up.

Thanks,

German

On Mon, Aug 28, 2017 at 4:05 PM, mjbcswitzerland <admin@community.nxp.com>

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

mjbcswitzerland — Tue, 29 Aug 2017 10:05:51 GMT

Hi German

There is nothing needed after returning from STOP mode to RUN mode - the clocks that had stopped will automatically be re-enabled and the peripherals fully functional again.

If neither UART nor Systick are operating afterwards there must be another problem involved (eg. the GPIO wake-up may be causing the wake up to take place but not be handled correctly to allow the code to continue correctly (?)).

Attached is the low power control module from the uTasker project (you will see it does nothing special on return from WFI in STOP mode) as reference - you can get a complete and fully operating K64 low power solution on GITHUB or take the required pieces from it if you prefer.

Regards

Mark

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

germanrivera — Wed, 30 Aug 2017 04:57:39 GMT

Hi Mark,

Thanks again. I finally found my problem. The key to the problem that I was

having is in the following text:

*(from the K64F RM - Chapter 25 Multipurpose Clock Generator (MCG), table

25-3)*

NOTE:

*• When entering Low Power Stop modes (LLS or VLPS) from PEE mode, on exit

the*

MCG clock mode is forced to PBE clock mode. C1[CLKS] and S[CLKST] will be

*configured to 2’b10if entering from PEE mode or to 2’b01 if entering from

PEI mode,*

*C5[PLLSTEN0] will be force to 1'b0 and S[LOCK] bit will be cleared without

setting*

*• When entering Normal Stop mode from PEE mode and if C5[PLLSTEN]=0, on

exit*

*the MCG clock mode is forced to PBE mode, the C1[CLKS] and S[CLKST] will

be*

configured to 2’b10 and S[LOCK] bit will clear without setting S[LOLS]. If

*C5[PLLSTEN]=1, the S[LOCK] bit will not get cleared and on exit the MCG

will*

continue to run in PEE mode.

I'm initialzingthe MCG clock mode to be PEE at boot time. From the note

above, the

MCG clcok mode is switched to PBE when waking up from LLS stop mode. This

was causing the UART and the Systick timer to stop working. All I needed to

do in the LLWU ISR was to set the MCG clock mode back to PEE.

Thanks,

German

On Tue, Aug 29, 2017 at 3:06 AM, mjbcswitzerland <admin@community.nxp.com>

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

mjbcswitzerland — Wed, 30 Aug 2017 10:14:34 GMT

German

Yes, the exit from LLS or VLPS requires the PLL to be reconfigured (if being used).

However, your thread suggests that you were exiting from STOP mode (sleepdeep + wfi) which is why I wrote that there is nothing else needed.

Regards

Mark

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

schw_gld — Tue, 25 Sep 2018 08:09:50 GMT

Hello,

although this thread is already a year old, I'd like to add some information, because I ran into the same problem on a K22-MCU:
The PLL does not need to be reconfigured when trying to wake up to PEE mode (from Stop or LLS/VLPS). But the MCG_C1_CLKS does! The PLL (and OSC, etc) is restored during the power-transition, but it's output is not selected for MCGOUTCLK (25.4.1 in the reference manual of K22FN512xxx12).

The most simple way to achieve this is to save the C1 register before executing WFI and restoring it afterwards:

uint8_t mcg_c1_bac = MCG->C1;
__WFI();
MCG->C1 = mcg_c1_bac;‍‍‍

Keep in mind, that the MCG will not be configured to PEE mode until the register is restored. This means that the wake-up interrupt (and following interrupts before regular execution) will be executed in PBE mode (typically slower).

Re: UART0 does not respond after waking up from STOP mode on Kinetis K64F

mjbcswitzerland — Wed, 26 Sep 2018 13:43:16 GMT

Hi Eike

Yes, the MCG configuration is a part of the recovery process and required for the final transition to PEE.

    register unsigned char ucMCG_C1;
    ucMCG_C1 = MCG_C1;                      // backup the original MCG_C1 setting
...// sleep
  //LLS/VLPS sleep mode exit
    MCG_C5 = ((CLOCK_DIV - 1) | MCG_C5_PLLSTEN0); // move from state FEE to state PBE (or FBE) PLL remains enabled in normal stop modes
    MCG_C6 = ((CLOCK_MUL - MCG_C6_VDIV0_LOWEST) | MCG_C6_PLLS);
    while ((MCG_S & MCG_S_PLLST) == 0) {    // loop until the PLLS clock source becomes valid
    }
    while ((MCG_S & MCG_S_LOCK) == 0) {     // loop until PLL locks
    }
    MCG_C1 = ucMCG_C1;                      // finally move from PBE to PEE mode - switch to PLL clock (the original settings are returned)
    while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST_PLL) { // loop until the PLL clock is selected
    }
‍‍‍‍‍‍‍‍‍‍‍‍‍

The PLL reconfiguration may be optional.

Regards

Mark