DM368 can not jump back to C code after deep sleep

Kenneth,

Have you enabled a print or glowing LED after the davinci_cpu_suspend() call? If you can use a debugger, you can find out where exactly its going out from the routine.

Hi,

We are having exact the same problem, when running almost identical code.

In our setup PLL's and DDR mem are not modified (self refresh).

We have used JTAG and found that the first instruction executed from DDR memory, after exit from DEEPSLEEP fails.

Any solution to this problem?

Best regads

Jakob

Jakob,

Which is the first instruction that you are running after sleep? What is the state of the processor when it fails?

Are you running the code from IRAM? If not, you'll have to make sure that the i-cache is NOT flushed/invalidated before sleep.

Hi Renjith,

Thank you very much for your reply, hope we can get this working.

The ARM core is executing the following code from IRAM in ARM-mode:

                             <snip>

            /* Go to deep sleep */

            ldr         ip, [r4]

            orr         ip, ip, #DEEPSLEEP_SLEEPENABLE_BIT

            /* System goes to sleep beyond after this instruction */

            str         ip, [r4]

zzz:

            ldr         ip, [r4]

            tst ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT

            beq zzz

            /* Wake up from sleep */

            /* Clear sleep enable */

            ldr         ip, [r4]

                             <snip>

I don't think the ARM core stops executing during DEEPSLEEP?

Note the code is not using "wait-for-interrupt" yet, but simply polls the SLEEP_COMPLETE bit. Please observe that execution continues just fine inside the IRAM.

At the end of the IRAM routine, execution "returns" to DDR memory using the instruction:

                             <snip>

            /* Restore registers and return */

            ldmfd   sp!, {r0-r12, pc}

Jumps back to code in DDR ram (observed by inspecting pc after the load). I therefore conclude that the load-instruction succeeds. However the first instruction in DDR ram fails.

Disassembly of the returned-to C-routine looks as follows:

            mov         lr, pc                   /* Setup for "return", this magically lets lr=pc+8 */

            ldr         pc, [r4, #4]             /* Jump to IRAM (function-pointer) */

            ldr         r3, [pc, #144]           /* Returned-to instruction, execution of this instruction fails (execution jumps to exception-vector) */

            ldr         r2, [r3, #76]            /* Never reached */

Final observation: If either the DEEPSLEEP bit isn't set, or the GPIO0 is not toggled low, and the "zzz" loop is simply skipped (So system never really sleeps), execution resumes from DDR ram just fine, and Linux is up-and-running again.

Jakob,

Is DDR up from self-refresh mode when you execute the first instruction?

Hi Renjith,

Not sure if DDR is "up", is there a statusbit indicating this?

The DDR PLL is not stopped in my test (X2_CLK), so its clock ought to remain stable even if DEEPSLEEP bit is set, right? The documentation is a little vague on this IMHO.

Regarding DDR, the code executed from IRAM does the following:

0) caches are flushed

1) SDCR.SRPD bit is cleared and SDCR.LPMODEN is set

2) SDCR.MCLKSTOPEN bit is set

3) DDR2 LPSC is disabled

4) System enters DEEPSLEEP

5) DDR2 LPSC is re-enabled

6) SDCR.MCLKSTOPEN is cleared

7) SDCR.LPMODEN is cleared

execution then "returns" to DDR a few instructions later.

However, according to SPRUF12 section 2.9:

"if a request for a memory access is received, the DDR2/mDDR memory controller services the memory access request"

From this I concluded, that DDR memory would be accessible even if the controller is in self-refresh mode …

Best regards,

Jakob

Jakob,

Sorry for the delayed response. What is the state of the processor when it fails? Is it in Abort mode? If so, you need to find out whether its pretetch abort or data abort. I feel that instruction fetch itself has failed.

Hi Jakob

Did you ever manage to get deepsleep working on the dm365.

I am also trying (for quite some time now) to get deep sleep working however, I am unable to wake up from deep sleep. The steps I followed are:

• Put cpu pll into bypass (clear pllensrc and pllen in pllctl register)
• Power down cpu pll (set pllpwrdwn in pllctl register)
• Set deepsleep wakeup delay to 128
• In SRAM:
  • Put ddr in self refresh (clear srpd and set lpmoden of sdrcr register)
  • Stop MCLK (set mclkstopen of sdrcr)
  • Disable DDR2 LPSC (Module 13 of PSC modules (table 39 of SPRUFG5A))
  • Disable clock to DDR PHY (clear plldiven of plldiv7 register)
  • Go into deep sleep (set deep sleep enable bit)
  • Poll sleep complete bit of deep sleep register (while in this loop the  a micro controller causes gpio0 to transition from high to low)
  • I am having an issue at this point as I am unable to wake up from sleep. I am using the micro controller to transition the gpio0 from low to high, which according to SPRUFG5A should wake it up from deep sleep.
  • If woken up, then remove deep sleep enable (clear deep sleep enable)
  • Enable clock to DDR PHY
  • Enable DDR LPSC
  • Start MCLK
  • Take ddr out of self refresh
• Power up cpu pll (clear pllpwrdwn in pllctl)
• Put cpu pll in bypass mode
• Reset cpu pll
• Do pllsecctl sequence 
• Poll the lock bits of pllc2_config register 
• Continue as normal...

If I remove the step to poll the deep sleep complete bit in the deep sleep register, the arm does not receive the transition of gpio0 from high to low and hence does not go into deep sleep. In this case, the program continues as normal and restarts everything as expected.

Any help/tips will be much appreciated.

Arshad

As you know, davinci_cpu_suspend() is run in sram. After wakeup it can control LEDs within the block. But when jump out, the CPU halt. I have an xds560, I don't know how to debug Linux kernel. Someone tell me xds560 can not debug Linux.

I was finally able to get Deep Sleep working for the DM368.  See my other E2E post for the final solution/patch:  https://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/448309/1644628#1644628