K25 LLS wakeup results in COP reset

[matthews]

I am running software on a K25. I successfully can enter and exit LLS low power mode when the watchdog COP is not enabled. I am using the LPTMR to wakeup the processor every 120 seconds. (Code resembles the example found here: Starting Point for Kinetis Low Power LLS Mode | MCU on Eclipse )

When I wakeup from LLS with no watchdog enabled code execution resumes on the instruction following the WFI. With the watchdog enabled, code execution also resumes after the WFI. I immediately service the watchdog but the processor resets with a COP reset shortly after waking up. Any ideas why the watchdog is tripping even though I am servicing it?

The watchdog is using the LPO 1 kHz clock. The reference manual indicates when the 1 kHz clock source is selected, the COP counter is re-initialized to zero upon entry to either debug mode or stop (including VLPS or LLS) mode. The counter begins from zero upon exit from debug mode or stop mode. Something isn't adding up.

My watchdog timeout is set to 1.024 seconds.

[mjbcswitzerland]

Hi

>>I immediately service the watchdog but the processor resets with a COP reset shortly after waking up. Any ideas why the watchdog is tripping even though I am servicing it?

Please specify how many ms are referred to by "shortly after waking up"

Since the counter is at 0 when exiting from LLS an immediate retrigger will not have any affect on it (it will just reset the 0 counter to 0).

When is the next watchdog retrigger taking place?

Regards

Mark

[matthews]

Hi Mark,

Thank you for the feedback. In response to your question I "shurnk" my code so that there was only a while(1) with a LED toggle, watchdog kick, and small delay. This reduced code works correctly in that the watchdog doesn't trip. This means there is something else in my code after wakeup that is delaying the watchdog kick.

My main execution loop wakes up on a PIT interrupt. The interrupt fires every 1 msec and a flag is set to indicate an execution cycle should begin every 250 interrupts. This yields a 250 msec cycle time. On exit from sleep mode the watchdog is tripping after about 172 of these 1 msec interrupts. Looking at the Processor Expert Cpu_SetOperationMode() it appears the clock is being configured differently after wakeup than at __init_hardware(). I don't have a scope available but I'm thinking the clock is running slower after wakeup than it ran prior to sleep mode.

Cpu_SetOperationMode()

...

      if ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST(3)) { /* If in PBE mode, switch to PEE. PEE to PBE transition was caused by wakeup from low power mode. */

        /* MCG_C1: CLKS=0,IREFS=0 */

        MCG_C1 &= (uint8_t)~(uint8_t)((MCG_C1_CLKS(0x03) | MCG_C1_IREFS_MASK));                                  

        while( (MCG_S & MCG_S_LOCK0_MASK) == 0x00U) { /* Wait for PLL lock */

        }

      }

...

__init_hardware()

/* MCG_C1: CLKS=2,FRDIV=3,IREFS=0,IRCLKEN=1,IREFSTEN=0 */

  MCG_C1 = (MCG_C1_CLKS(0x02) | MCG_C1_FRDIV(0x03) | MCG_C1_IRCLKEN_MASK);

Thank you for pointing me in the right direction.

[matthews · Accepted solution]

On wakeup, I added a call to __init_hardware() as the first line of code executed. This resolved the problem.

[mjbcswitzerland]

Hi

LLS stops the PLL so it is correct that you need to reconfigure it on each exit from LLS to return original system timings.

Note that there is a PLL lock delay involved, which limits the speed of transition in and out of LLS, which needs to be considered in systems with high transition rate.

Regards

Mark