AnsweredAssumed Answered

i.MX6 solo resume from suspend (DSM) problem

Question asked by Bill Lau on Jul 4, 2014
Latest reply on Sep 27, 2014 by igorpadykov

Hi all,


Background of hardware and software used.


  1. Freescale or other standard reference board used = custom design board
  2. Kernel version and/or BSP release used = based on 3.0.35
  3. Any additional software/application or hardware used = i.MX6 Solo, 512MB DDR2 RAM (Micron MT42L128M32D1LF-18 WT:A @396MHz), 1GB NAND flash (Toshiba TC58NYG3S0FBAID)

Recently, we found about 1% of our production yield (an android phone based on i.MX6 solo) had a problem which fail to resume normally from suspend mode (DSM).

We checked the failure unit could work  normally before DSM. But once it went to DSM, it cannot resume anymore unless cold start or hard reset.

I have gone though some discussion in the forum, the resume procedure from DSM should be:

In a word, for exiting from DSM, the analog will take < 1mS to prepare normal working power(voltage up from standby mode to normal mode), then waiting timer to count down, about 0.5mS before re-power OSC, then OSC takes about 2mS to lock, but we wait for about 8ms to make sure OSC is enabled, then PLL takes about 0.45mS to re-lock, then wait for another 2mS to re-power the ARM core and another 2mS to reset ARM core. So it takes about 14mS to exit from STOP mode, here exit means ARM core restart to run.

Our observation :

1. During DSM, the internal regulator PU and ARM regulator are disabled  (VDD_ARM_CAP, VDD_PU_CAP dropped below 300mV),  VDD_SOC_CAP = VDD_SOC_IN (SoC regulator was by-pass), 24M OSC has been shutdown.

2. Pressing the button on the phone would trigger an wake up event to i.MX6 by an interrupt pin

3. Starting from the negative edge at the interrupt pin, VDD_SOC_CAP = 1.2V (SoC regulator was no longer by-pass)

4. And then after 1.1ms, PMIC_STBY_REQ was de-asserted.

5. And then after 1.6ms, the 24M OSC started to oscillate. and took additional 2.4ms to become stable

6. After further 5.3ms, the VDD_ARM_CAP was established.

7. Then here came a difference compare to normal units and failure units. After the VDD_ARM_CAP setup, a normal unit will successfully setup VDD_PU_CAP after 3ms.

But for failure units, VDD_PU_CAP will always keep  below 300mV and never rise to 1.2V.

8. When the resume was fail, the kernel was not running. current consumption kept at same level steadily

So, it seems that there was a failure after VDD_ARM_CAP has powered up. At that moment, the ARM core should be reset. My assumption is that it locked up at that ARM core reset  and  then VDD_PU_CAP could not be powered up normally.

-We also tried to supply VDD_ARM_CAP, VDD_PU_CAP externally. But the resume from DSM was still not successful.

-We also try to trigger the ONOFF pin in the iMX6 instead of interrupt pin to wake up from DSM. It had the same behavior mentioned above.



1. What possible causes could make the VDD_PU_CAP not able to setup?

2. In our custom board, VDD_PU_CAP has no external load. And we only added one 22u bulk capacitor stated in the requirement. And all power rail (VDD_ARM_IN, VDD_SOC_IN, VDD_HIGH_IN, VDD_SNVS_IN, DRAM VDD) were kept unchanged during DSM. Suppose the failure should not be a power source problem. Do you agree?

3. Is it related to DRAM problem? (fail to refresh during DSM or restore all setting after resume)

4. What else we can measure in hardware to secure a resume from DSM?