AnsweredAssumed Answered

K20 entry to VLLSx power modes

Question asked by deadwoods on Dec 12, 2012
Latest reply on Jan 10, 2013 by deadwoods

Hi all,


We're trying to get low-power mode (specifically VLLS1) working on a K20FX512 part. We're running MQX as the operating system and using many peripherals. We're not attempting to use the MQX LPM driver, as we've written our own power management software. The problem is that we're unable to get the K20 to enter into any of the VLLSx modes.


I've read all of the application notes relating to low-power mode as well as the errata for our part (which has the production mask). The sequence we're following to enter VLLSx is as follows:


  • Configure LLWU sources and clear LLWU flags.
  • Set SLEEPDEEP bit in SCB_SCR and clear the SLEEPONEXIT bit.
  • Set PMPROT to 0x02 to allow VLLSx modes. Note that I've checked this isn't written anywhere else, and checked that it gets set to 0x02 after writing.
  • Set SMC_PMCTRL to 0x04 to select VLLSx, then do a dummy synchronisation read.
  • Set SMC_VLLSCTRL to 0x01 to select VLLS1.
  • Execute the WFI instruction.


Now, what usually happens is that we don't enter stop mode. The STOPA bit of SMC_PMCTRL is set, so something is causing it to abort. I noted that there were a couple of interrupts still firing (FTM1 and SysTick). After disabling those, the micro tries to enter stop mode, but after ~1 second it resets. After the reset, the SACKERR bit of RCM_SRS1 is set.


Unfortunately the documentation gets a bit sparse at this point. It's clear that we're not entering stop mode due to at least one of the peripherals failing to acknowledge the stop request, but it isn't clear which peripherals are polled, and under what conditions they can fail to acknowledge. Has anyone here run into similar problems and if so, are there any tips on how to debug which peripheral is causing this?


For reference, we're using a lot of peripherals on the board (UART, SPI, eSDHC, CAN, GPIO, ADC, FTM). Prior to going into stop mode, our power manager will disable each peripheral, put its pins into a power-saving state (to ensure we don't draw current) and gate off the clock to the peripheral. Could it be this clock gating that is causing the failure to acknowledge the sleep request? Or that we haven't fully or correctly disabled all peripherals?


Thanks in advance for any input,