• State Resolved
  • Locked Locked
  • Replies 77 replies
  • Subscribers 101 subscribers
  • Views 14597 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3354 Standby Resume issues with DDR3 Using Two 8-bit DDR3 devices

Jonathan Cormier
Genius 3575 points
Other Parts Discussed in Thread: AM3354

I am trying to get standby/resume working on our custom AM3354 based module.  The board has two MT41K256M8DA-125 Micrel modules.  

I have been able to reproduce the standby functionality using a BBB running the debian wheezy filesystem and the 3.14 ti kernel.  

Booting the same kernel and filesystem on our board does not work.  The system is able to go into standby but when the spacebar is pressed the system doesn't resume.  I am able to see the power usage increase after trying to wake up the device and the reset button starts functioning.

My question is has anyone tested sleep mode when using 2 DDR3 modules?  Is it possible that the 2 DDR3 setup could be the cause of this failure? What steps can I take to narrow down the cause of this problem.

Thanks

Jonathan Cormier

  • 0 in reply to Jonathan Cormier
    Genius 3575 points
    Tested sleep using the 3.14 kernel on our DDR3 module. And was able to enter and exit both standby and mem. So seems like there may be a bug in the deep sleep resume code of the 3.2 kernel.

    root@mitysom-335x ~ $ rtcwake -s 4 -m mem -d /dev/rtc0
    wakeup from "mem" at Fri Dec 30 21:06:08 2011
    [ 3568.747889] PM: Syncing filesystems ... done.
    [ 3568.754193] Freezing user space processes ... (elapsed 0.001 seconds) done.
    [ 3568.762876] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
    [ 3568.772026] Suspending console(s) (use no_console_suspend to debug)
    [ 3568.784710] PM: suspend of devices complete after 5.191 msecs
    [ 3568.785588] PM: late suspend of devices complete after 0.850 msecs
    [ 3568.786884] PM: noirq suspend of devices complete after 1.267 msecs
    [ 3568.787016] PM: Successfully put all powerdomains to target state
    [ 3568.787016] PM: Wakeup source RTC Alarm
    [ 3568.803916] PM: noirq resume of devices complete after 16.809 msecs
    [ 3568.804885] PM: early resume of devices complete after 0.625 msecs
    [ 3568.805563] net eth0: initializing cpsw version 1.12 (0)
    [ 3568.879023] net eth0: phy found : id is : 0x70421
    [ 3568.879136] libphy: PHY 4a101000.mdio:02 not found
    [ 3568.879155] net eth0: phy 4a101000.mdio:02 not found on slave 1
    [ 3568.968530] tilcdc 4830e000.lcdc: timeout waiting for framedone
    [ 3569.033152] PM: resume of devices complete after 228.228 msecs
    [ 3569.125980] Restarting tasks ... done.
    root@mitysom-335x ~ $ [ 3571.879441] libphy: 4a101000.mdio:01 - Link is Up - 1000/Full
    root@mitysom-335x ~ $ rtcwake -s 4 -m standby -d /dev/rtc0
    wakeup from "standby" at Fri Dec 30 21:06:23 2011
    [ 3580.891838] PM: Syncing filesystems ... done.
    [ 3580.897996] Freezing user space processes ... (elapsed 0.001 seconds) done.
    [ 3580.906684] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
    [ 3580.915862] Suspending console(s) (use no_console_suspend to debug)
    [ 3580.928629] PM: suspend of devices complete after 5.275 msecs
    [ 3580.929509] PM: late suspend of devices complete after 0.853 msecs
    [ 3580.930792] PM: noirq suspend of devices complete after 1.254 msecs
    [ 3580.930922] PM: Successfully put all powerdomains to target state
    [ 3580.930922] PM: Wakeup source RTC Alarm
    [ 3580.947668] PM: noirq resume of devices complete after 16.656 msecs
    [ 3580.948680] PM: early resume of devices complete after 0.665 msecs
    [ 3580.949354] net eth0: initializing cpsw version 1.12 (0)
    [ 3581.028989] net eth0: phy found : id is : 0x70421
    [ 3581.029105] libphy: PHY 4a101000.mdio:02 not found
    [ 3581.029125] net eth0: phy 4a101000.mdio:02 not found on slave 1
    [ 3581.118454] tilcdc 4830e000.lcdc: timeout waiting for framedone
    [ 3581.183053] PM: resume of devices complete after 234.334 msecs
    [ 3581.260948] Restarting tasks ... done.
    root@mitysom-335x ~ $ [ 3584.029282] libphy: 4a101000.mdio:01 - Link is Up - 1000/Full
  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    I forgot you were on 3.2.  BBB required this patch with SDK 6.00 (3.2 kernel) in order for suspend/resume to work:

       Patch to fix suspend/resume for BeagleBone Black

    diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S

    index 1ee0b1a..8e4aa19 100644

    --- a/arch/arm/mach-omap2/sleep33xx.S

    +++ b/arch/arm/mach-omap2/sleep33xx.S

    @@ -789,6 +789,10 @@ sdram_ref_ctrl:

           str     r4, [r3, #EMIF4_0_SDRAM_REF_CTRL_SHADOW]

    pmcr:

           ldr     r4, emif_pmcr_val

    +       bic     r4, r4, #0x0700

    +       orr     r4, r4, #0x0200

    +       str     r4, [r3, #EMIF4_0_SDRAM_MGMT_CTRL]

    +       bic     r4, r4, #0x0700

           str     r4, [r3, #EMIF4_0_SDRAM_MGMT_CTRL]

    pmcr_shdw:

           ldr     r4, emif_pmcr_shdw_val

    Simply moving to 3.14 is the much better solution though if possible.  There has been a ton of work related to suspend resume in the more recent kernels so if that's an important feature then I would definitely go with the newer kernels.  We recently released a 4.1 kernel as well (Processor SDK 2.00).

  • 0 in reply to Brad Griffis
    Genius 3575 points

    Brad thanks for the patch.  Just tested it and it worked.

    Part of the reason for supporting sleep in 3.2 was its currently the kernel needed for the rowboat android. We hope to be able to use the 3.14 or newer kernel but having 3.2 working gives us a fallback.

    Somehow I missed the announcement of SDK 2.00.  Will have to check it out.

  • 0 in reply to Jonathan Cormier
    Genius 3575 points
    Btw it appears that if the remote_proc module isn't given a firmware to load to the pruss it causes a kernel dump when resuming from sleep. Not loading the module on boot avoids this problem. Power usage during sleep is higher when this happens.

    [ 5.064351] remoteproc1: 4a334000.pru0 is available
    [ 5.069588] remoteproc1: Note: remoteproc is still under development and considered experimental.
    [ 5.078934] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
    [ 5.098817] remoteproc1: Direct firmware load failed with error -2
    [ 5.105414] remoteproc1: Falling back to user helper
    [ 9.280098] remoteproc1: failed to load rproc-pru0-fw
    [ 9.285580] pru-rproc 4a334000.pru0: booting the PRU core manually
    [ 9.313091] remoteproc1: powering up 4a334000.pru0
    [ 9.397752] remoteproc1: Direct firmware load failed with error -2
    [ 9.404423] remoteproc1: Falling back to user helper
    [ 9.530309] remoteproc1: request_firmware failed: -2
    [ 9.535638] pru-rproc 4a334000.pru0: rproc_boot failed
    [ 9.576436] pru-rproc: probe of 4a334000.pru0 failed with error -2

    This repeats for pru1


    root@mitysom-335x ~ $ echo mem > /sys/power/state
    [ 761.283007] PM: Syncing filesystems ... done.
    [ 761.326126] Freezing user space processes ... (elapsed 0.001 seconds) done.
    [ 761.334873] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
    [ 761.344099] Suspending console(s) (use no_console_suspend to debug)
    [ 761.574236] PM: suspend of devices complete after 222.332 msecs
    [ 761.575320] PM: late suspend of devices complete after 1.055 msecs
    [ 761.576403] ------------[ cut here ]------------
    [ 761.576468] WARNING: CPU: 0 PID: 2478 at arch/arm/mach-omap2/omap_hwmod.c:2270 _idle+0x204/0x250()
    [ 761.576479] omap_hwmod: pruss: idle state can only be entered from enabled state
    [ 761.576528] Modules linked in: musb_dsps musb_hdrc m25p80 pruss_remoteproc c_can_platform c_can can_dev musb_am335x
    [ 761.576556] CPU: 0 PID: 2478 Comm: sh Tainted: G W 3.14.26-02663-gb49d343d692b #46
    [ 761.576568] Backtrace:
    [ 761.576619] [<c0011294>] (dump_backtrace) from [<c0011430>] (show_stack+0x18/0x1c)
    [ 761.576647] r6:000008de r5:00000009 r4:ddf2fd48 r3:00000000
    [ 761.576682] [<c0011418>] (show_stack) from [<c05af4b4>] (dump_stack+0x20/0x28)
    [ 761.576719] [<c05af494>] (dump_stack) from [<c0038764>] (warn_slowpath_common+0x6c/0x8c)
    [ 761.576746] [<c00386f8>] (warn_slowpath_common) from [<c0038828>] (warn_slowpath_fmt+0x38/0x40)
    [ 761.576777] r8:dd8ca010 r7:dd8ca000 r6:dd8ce500 r5:dd8ce500 r4:c081da44
    [ 761.576805] [<c00387f4>] (warn_slowpath_fmt) from [<c002488c>] (_idle+0x204/0x250)
    [ 761.576821] r3:c0716194 r2:c0713ea8
    [ 761.576848] [<c0024688>] (_idle) from [<c0024e10>] (omap_hwmod_idle+0x20/0x34)
    [ 761.576863] r5:dd8ce500 r4:a0000013
    [ 761.576889] [<c0024df0>] (omap_hwmod_idle) from [<c0026454>] (omap_device_idle+0x44/0x80)
    [ 761.576904] r4:00000001 r3:dd8ce4c0
    [ 761.576924] [<c0026410>] (omap_device_idle) from [<c002652c>] (_od_suspend_noirq+0x70/0x80)
    [ 761.576939] r5:00000000 r4:dd8ca010
    [ 761.576977] [<c00264bc>] (_od_suspend_noirq) from [<c0364450>] (dpm_run_callback.isra.6+0x34/0x6c)
    [ 761.577002] r7:c00264bc r6:00000000 r5:00000000 r4:00000000
    [ 761.577030] [<c036441c>] (dpm_run_callback.isra.6) from [<c0365034>] (dpm_suspend_end+0x290/0x530)
    [ 761.577060] r8:c083aa88 r7:00000002 r6:00000000 r5:c083aa74 r4:dd8ca010
    [ 761.577095] [<c0364da4>] (dpm_suspend_end) from [<c0060db0>] (suspend_devices_and_enter+0x150/0x320)
    [ 761.577129] r10:c0717b04 r9:00000004 r8:c0812be0 r7:c085cc80 r6:00000000 r5:00000003
    [ 761.577138] r4:c085cc80
    [ 761.577164] [<c0060c60>] (suspend_devices_and_enter) from [<c00611f4>] (pm_suspend+0x274/0x2b4)
    [ 761.577198] r10:c0717b04 r8:c08230e0 r7:ddb8fa80 r6:c08230b8 r5:00000003 r4:00000000
    [ 761.577221] [<c0060f80>] (pm_suspend) from [<c005fdc0>] (state_store+0x78/0xdc)
    [ 761.577246] r6:00000003 r5:00000003 r4:c08230d8 r3:0000006d
    [ 761.577277] [<c005fd48>] (state_store) from [<c02654a8>] (kobj_attr_store+0x1c/0x28)
    [ 761.577312] r10:ddb8f700 r9:ddb8f708 r8:ddb8fa80 r7:00000004 r6:ddf2ff78 r5:ddb8fa80
    [ 761.577326] r4:dd896678 r3:00000004
    [ 761.577352] [<c026548c>] (kobj_attr_store) from [<c012858c>] (sysfs_kf_write+0x4c/0x50)
    [ 761.577381] [<c0128540>] (sysfs_kf_write) from [<c012beb4>] (kernfs_fop_write+0xbc/0x154)
    [ 761.577396] r5:00000000 r4:00000000
    [ 761.577431] [<c012bdf8>] (kernfs_fop_write) from [<c00cc774>] (vfs_write+0xb4/0x18c)
    [ 761.577465] r10:b6f7e000 r9:ddf2e000 r8:00000004 r7:ddf2ff78 r6:b6f7e000 r5:00000004
    [ 761.577475] r4:ddbefd80
    [ 761.577500] [<c00cc6c0>] (vfs_write) from [<c00ccb50>] (SyS_write+0x44/0x90)
    [ 761.577534] r10:b6f7e000 r8:00000004 r7:ddbefd80 r6:ddbefd80 r5:00000000 r4:00000000
    [ 761.577564] [<c00ccb0c>] (SyS_write) from [<c000e800>] (ret_fast_syscall+0x0/0x30)
    [ 761.577598] r10:00000000 r8:c000e984 r7:00000004 r6:b6ee95d0 r5:b6f7e000 r4:00000004
    [ 761.577607] ---[ end trace 6736cafc681f3e64 ]---
    [ 761.578067] PM: noirq suspend of devices complete after 2.718 msecs
    [ 761.578211] PM: Could not transition all powerdomains to target state
    [ 761.578211] PM: Wakeup source UART
    [ 761.598525] PM: noirq resume of devices complete after 20.155 msecs
    [ 761.599560] PM: early resume of devices complete after 0.802 msecs
    [ 761.600506] net eth0: initializing cpsw version 1.12 (0)
    [ 761.678809] net eth0: phy found : id is : 0x70421
    [ 761.678925] libphy: PHY 4a101000.mdio:02 not found
    [ 761.678944] net eth0: phy 4a101000.mdio:02 not found on slave 1
    [ 761.898600] PM: resume of devices complete after 298.993 msecs
    [ 762.285945] Restarting tasks ... done.
  • 0 in reply to Jonathan Cormier
    Genius 3575 points

    Brad,


    Comparing power usage between our DDR2 and DDR3 module.  I am seeing an increase of about 300mW for the DDR3 module when cpu is idle and when stressed.  And a 84mW increase when comparing mem sleep state.  Power measurements were taken using the same 3.14 kernel. 


    Does this power increase make sense or should I be looking for power leaks? I expect 84mW difference to decrease some when we manage to disable VTT though not really sure how much power that would draw.

  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    The ODT+VTT likely accounts for the 300 mW you mentioned.  The 84mW increase however is unexpected.  There might be higher leakage for DDR3 than DDR2 though I don't have any estimates of what that is.  I wouldn't expect 84mW though as that sounds high.  A good starting point would be to step all the way to the end of the Cortex M3 sleep handler (right before it cuts the WKUP clock which kills JTAG) so that you can grab a fresh clock tree dump.  We can check to see if there are any power domains still on that might be causing an issue.

    Are you using PG2.1 or PG1.0 silicon?

  • 0 in reply to Brad Griffis
    Genius 3575 points

    Brad Griffis said:

    The ODT+VTT likely accounts for the 300 mW you mentioned.

    Whats the ODT?  And why would these affect the running power but not the sleep power?

    Brad Griffis said:

    The 84mW increase however is unexpected.  There might be higher leakage for DDR3 than DDR2 though I don't have any estimates of what that is.  I wouldn't expect 84mW though as that sounds high.  A good starting point would be to step all the way to the end of the Cortex M3 sleep handler (right before it cuts the WKUP clock which kills JTAG) so that you can grab a fresh clock tree dump.  We can check to see if there are any power domains still on that might be causing an issue.

    Are you using PG2.1 or PG1.0 silicon?

    For the sleep measurements the DDR2 module is PG1.0 and the DDR3 is PG2.1.  When comparing them at running both modules were PG1.0.  I could get one of my PG1.0 DDR3 modules modded to see if that makes a difference.

  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    Jonathan Cormier said:
    Whats the ODT?  And why would these affect the running power but not the sleep power?

    On Die Termination.  It would only affect running power because it's disabled during sleep.  Same applies to VTT.

    Jonathan Cormier said:
    For the sleep measurements the DDR2 module is PG1.0 and the DDR3 is PG2.1.  When comparing them at running both modules were PG1.0.  I could get one of my PG1.0 DDR3 modules modded to see if that makes a difference.

    There were several power related fixes in PG2.1, so generally speaking that should be lower power.

  • 0 in reply to Brad Griffis
    Genius 3575 points
    Ahh ODT/VTT is not disabled in our modules since we don't have a hardware mod for that yet.

    They should use less power even with the higher cpu frequency? 720Mhz -> 800Mhz?
  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    Jonathan Cormier said:
    They should use less power even with the higher cpu frequency? 720Mhz -> 800Mhz?

    DeepSleep0 (DS0) should consume less power for PG2.1 than PG1.0.  This is true for all speed grades.

  • 0 in reply to Brad Griffis
    Genius 3575 points
    That makes sense. Perhaps some of the extra power usage is coming from the extra memory chip. Our DDR2 modules have 1 chip and the DDR3 modules have 2 chips.
  • 0 in reply to Jonathan Cormier
    Genius 3575 points

    Placed inifinite loops in a8_lp_ds0_handler and a8_lp_ds1_handler right before the  clkdm_sleep(CLKDM_WKUP); lines.  Attached the ctt dumps from before sleep and during sleep.


    am335x-ctt_2015-10-21_165510_ddr3_mem_before.rd1.txt 
    DeviceName AM335x1.0
0x44e00000 0x00024502
0x44e00004 0x0000000a
0x44e00008 0x00000102
0x44e0000c 0x00000056
0x44e00010 0x00070000
0x44e00014 0x00000002
0x44e00018 0x00000002
0x44e0001c 0x00000002
0x44e00020 0x00070000
0x44e00024 0x00000002
0x44e00028 0x00000002
0x44e0002c 0x00000002
0x44e00030 0x00000002
0x44e00034 0x00030000
0x44e00038 0x00030000
0x44e0003c 0x00030000
0x44e00040 0x00000002
0x44e00044 0x00030000
0x44e00048 0x00030000
0x44e0004c 0x00030000
0x44e00050 0x00030000
0x44e00054 0x00030000
0x44e00058 0x00030000
0x44e00060 0x00000002
0x44e00064 0x00000002
0x44e00068 0x00030000
0x44e0006c 0x00030000
0x44e00070 0x00030000
0x44e00074 0x00000002
0x44e00078 0x00000002
0x44e0007c 0x00030000
0x44e00080 0x00000002
0x44e00084 0x00030000
0x44e00088 0x00030000
0x44e0008c 0x00030000
0x44e00090 0x00000002
0x44e00094 0x00030000
0x44e00098 0x00030000
0x44e0009c 0x00030000
0x44e000a0 0x00030000
0x44e000a4 0x00030000
0x44e000a8 0x00030000
0x44e000ac 0x00030000
0x44e000b0 0x00000002
0x44e000b4 0x00000002
0x44e000b8 0x00030000
0x44e000bc 0x00000002
0x44e000c0 0x00030000
0x44e000c4 0x00030000
0x44e000c8 0x00030000
0x44e000cc 0x00030000
0x44e000d0 0x00000002
0x44e000d4 0x00000002
0x44e000d8 0x00030000
0x44e000dc 0x00000002
0x44e000e0 0x00000002
0x44e000e4 0x00040002
0x44e000e8 0x00070000
0x44e000ec 0x00030000
0x44e000f0 0x00030000
0x44e000f4 0x00030000
0x44e000f8 0x00030000
0x44e000fc 0x00000002
0x44e00100 0x00000002
0x44e00104 0x00030000
0x44e0010c 0x00030000
0x44e00110 0x00000002
0x44e0011c 0x0000007a
0x44e00120 0x00000002
0x44e00124 0x00070000
0x44e00128 0x00030000
0x44e0012c 0x00000012
0x44e00130 0x00040002
0x44e00134 0x00030000
0x44e00138 0x00030000
0x44e0013c 0x00030000
0x44e00140 0x00000002
0x44e00144 0x00000012
0x44e00148 0x00000012
0x44e0014c 0x00000002
0x44e00150 0x00000012
0x44e00400 0x00003606
0x44e00404 0x00000002
0x44e00408 0x00030000
0x44e0040c 0x00000002
0x44e00410 0x00000002
0x44e00414 0x12510000
0x44e00418 0x00000009
0x44e0041c 0x00000000
0x44e00420 0x00000000
0x44e00424 0x00000000
0x44e00428 0x00000000
0x44e0042c 0x00001901
0x44e00430 0x00000000
0x44e00434 0x00000001
0x44e00438 0x00000000
0x44e0043c 0x00000000
0x44e00440 0x00019017
0x44e00444 0x00000000
0x44e00448 0x00000001
0x44e0044c 0x00000000
0x44e00450 0x00000000
0x44e00454 0x00000501
0x44e00458 0x00000000
0x44e0045c 0x00000001
0x44e00460 0x00000000
0x44e00464 0x00000000
0x44e00468 0x0003e817
0x44e0046c 0x00000000
0x44e00470 0x00000001
0x44e00474 0x00000000
0x44e00478 0x00000000
0x44e0047c 0x00000300
0x44e00480 0x0000022a
0x44e00484 0x00000228
0x44e00488 0x00000005
0x44e0048c 0x00000007
0x44e00490 0x00000007
0x44e00494 0x00000007
0x44e00498 0x00000007
0x44e0049c 0x0403c017
0x44e004a0 0x00000201
0x44e004a4 0x00000201
0x44e004a8 0x00000001
0x44e004ac 0x00000285
0x44e004b0 0x00000002
0x44e004b4 0x00000002
0x44e004b8 0x00030000
0x44e004bc 0x00030000
0x44e004c0 0x00030000
0x44e004c4 0x00000002
0x44e004c8 0x00030000
0x44e004cc 0x00000006
0x44e004d0 0x00000002
0x44e004d4 0x00030000
0x44e004d8 0x00000004
0x44e00504 0x00000001
0x44e00508 0x00000001
0x44e0050c 0x00000001
0x44e00510 0x00000001
0x44e00514 0x00000004
0x44e00518 0x00000001
0x44e0051c 0x00000001
0x44e00520 0x00000000
0x44e00528 0x00000000
0x44e0052c 0x00000000
0x44e00530 0x00000000
0x44e00534 0x00000000
0x44e00538 0x00000001
0x44e0053c 0x00000000
0x44e00600 0x00000001
0x44e00604 0x00070000
0x44e00700 0x00000080
0x44e00800 0x00000002
0x44e00804 0x00000302
0x44e00900 0x00000001
0x44e00904 0x00070000
0x44e00908 0x00070000
0x44e0090c 0x00000001
0x44e00910 0x00030000
0x44e00914 0x00030000
0x44e00a00 0x00000001
0x44e00a20 0x00030000
0x44e00b00 0x00000000
0x44e00b04 0x00000500
0x44e00b08 0x00000000
0x44e00b0c 0x00000100
0x44e00b10 0x00000000
0x44e00c00 0x00000003
0x44e00c04 0x00000000
0x44e00c08 0x01e60007
0x44e00c0c 0x06000063
0x44e00d00 0x00000000
0x44e00d04 0x00000008
0x44e00d08 0x00000000
0x44e00d0c 0x00000020
0x44e00e00 0x00fc0003
0x44e00e04 0x000003f7
0x44e00e08 0x00000000
0x44e00f00 0x00000000
0x44e00f04 0x00001006
0x44e00f08 0x00000001
0x44e00f0c 0x78000017
0x44e00f10 0x00000003
0x44e00f14 0x00000000
0x44e00f18 0x00000003
0x44e00f1c 0x00000000
0x44e01000 0x00000004
0x44e01004 0x00000000
0x44e01100 0x00060047
0x44e01104 0x00000001
0x44e01110 0x00000037
0x44e01114 0x00000000
0x44e01200 0x00000000
0x44e01204 0x00000000
0x44e10040 0x004003f3

    am335x-ctt_2015-10-21_165519_ddr3_mem_during.rd1.txt 
    DeviceName AM335x1.0
0x44e00000 0x00000001
0x44e00004 0x00000001
0x44e00008 0x00000001
0x44e0000c 0x00000001
0x44e00010 0x00070000
0x44e00014 0x00070000
0x44e00018 0x00070000
0x44e0001c 0x00070000
0x44e00020 0x00070000
0x44e00024 0x00070000
0x44e00028 0x00030000
0x44e0002c 0x00030000
0x44e00030 0x00030000
0x44e00034 0x00030000
0x44e00038 0x00030000
0x44e0003c 0x00030000
0x44e00040 0x00030000
0x44e00044 0x00030000
0x44e00048 0x00030000
0x44e0004c 0x00030000
0x44e00050 0x00030000
0x44e00054 0x00030000
0x44e00058 0x00030000
0x44e00060 0x00030000
0x44e00064 0x00030000
0x44e00068 0x00030000
0x44e0006c 0x00030000
0x44e00070 0x00030000
0x44e00074 0x00030000
0x44e00078 0x00030000
0x44e0007c 0x00030000
0x44e00080 0x00030000
0x44e00084 0x00030000
0x44e00088 0x00030000
0x44e0008c 0x00030000
0x44e00090 0x00030000
0x44e00094 0x00030000
0x44e00098 0x00030000
0x44e0009c 0x00030000
0x44e000a0 0x00030000
0x44e000a4 0x00030000
0x44e000a8 0x00030000
0x44e000ac 0x00030000
0x44e000b0 0x00030000
0x44e000b4 0x00030000
0x44e000b8 0x00030000
0x44e000bc 0x00030000
0x44e000c0 0x00030000
0x44e000c4 0x00030000
0x44e000c8 0x00030000
0x44e000cc 0x00030000
0x44e000d0 0x00030000
0x44e000d4 0x00030000
0x44e000d8 0x00030000
0x44e000dc 0x00030000
0x44e000e0 0x00030000
0x44e000e4 0x00070000
0x44e000e8 0x00070000
0x44e000ec 0x00030000
0x44e000f0 0x00030000
0x44e000f4 0x00030000
0x44e000f8 0x00030000
0x44e000fc 0x00070000
0x44e00100 0x00070000
0x44e00104 0x00030000
0x44e0010c 0x00030000
0x44e00110 0x00030000
0x44e0011c 0x00000001
0x44e00120 0x00030000
0x44e00124 0x00070000
0x44e00128 0x00030000
0x44e0012c 0x00000001
0x44e00130 0x00060002
0x44e00134 0x00030000
0x44e00138 0x00030000
0x44e0013c 0x00030000
0x44e00140 0x00000001
0x44e00144 0x00000001
0x44e00148 0x00000001
0x44e0014c 0x00030000
0x44e00150 0x00000001
0x44e00400 0x00002606
0x44e00404 0x00000002
0x44e00408 0x00030000
0x44e0040c 0x00000002
0x44e00410 0x00000002
0x44e00414 0x12510000
0x44e00418 0x00000009
0x44e0041c 0x00000000
0x44e00420 0x00000000
0x44e00424 0x00000000
0x44e00428 0x00000000
0x44e0042c 0x00001901
0x44e00430 0x00000000
0x44e00434 0x00000000
0x44e00438 0x00000000
0x44e0043c 0x00000000
0x44e00440 0x00019017
0x44e00444 0x00000000
0x44e00448 0x00000000
0x44e0044c 0x00000000
0x44e00450 0x00000000
0x44e00454 0x00000501
0x44e00458 0x00000000
0x44e0045c 0x00000000
0x44e00460 0x00000000
0x44e00464 0x00000000
0x44e00468 0x0003e817
0x44e0046c 0x00000000
0x44e00470 0x00000000
0x44e00474 0x00000000
0x44e00478 0x00000000
0x44e0047c 0x00000000
0x44e00480 0x0000020a
0x44e00484 0x00000008
0x44e00488 0x00000005
0x44e0048c 0x00000005
0x44e00490 0x00000005
0x44e00494 0x00000005
0x44e00498 0x00000005
0x44e0049c 0x0403c017
0x44e004a0 0x00000001
0x44e004a4 0x00000001
0x44e004a8 0x00000001
0x44e004ac 0x00000085
0x44e004b0 0x00000002
0x44e004b4 0x00030000
0x44e004b8 0x00030000
0x44e004bc 0x00030000
0x44e004c0 0x00030000
0x44e004c4 0x00000002
0x44e004c8 0x00030000
0x44e004cc 0x00000006
0x44e004d0 0x00000002
0x44e004d4 0x00030000
0x44e004d8 0x00000004
0x44e00504 0x00000001
0x44e00508 0x00000001
0x44e0050c 0x00000001
0x44e00510 0x00000001
0x44e00514 0x00000004
0x44e00518 0x00000001
0x44e0051c 0x00000001
0x44e00520 0x00000000
0x44e00528 0x00000000
0x44e0052c 0x00000000
0x44e00530 0x00000000
0x44e00534 0x00000000
0x44e00538 0x00000001
0x44e0053c 0x00000000
0x44e00600 0x00000001
0x44e00604 0x00070000
0x44e00700 0x00000080
0x44e00800 0x00030000
0x44e00804 0x00000001
0x44e00900 0x00000001
0x44e00904 0x00070000
0x44e00908 0x00070000
0x44e0090c 0x00000001
0x44e00910 0x00030000
0x44e00914 0x00030000
0x44e00a00 0x00000001
0x44e00a20 0x00030000
0x44e00b00 0x00000000
0x44e00b04 0x00000500
0x44e00b08 0x00000000
0x44e00b0c 0x00000100
0x44e00b10 0x00000000
0x44e00c00 0x00000003
0x44e00c04 0x00000000
0x44e00c08 0x00200001
0x44e00c0c 0x0e000061
0x44e00d00 0x00000000
0x44e00d04 0x00000008
0x44e00d08 0x00000000
0x44e00d0c 0x00000020
0x44e00e00 0x003c0000
0x44e00e04 0x00000000
0x44e00e08 0x00000000
0x44e00f00 0x00000000
0x44e00f04 0x00001006
0x44e00f08 0x00000001
0x44e00f0c 0x78000017
0x44e00f10 0x00000003
0x44e00f14 0x00000000
0x44e00f18 0x00000003
0x44e00f1c 0x00000101
0x44e01000 0x00000004
0x44e01004 0x00000000
0x44e01100 0x00060044
0x44e01104 0x00000001
0x44e01110 0x00000000
0x44e01114 0x00000000
0x44e01200 0x00000000
0x44e01204 0x00000000
0x44e10040 0x004003f3

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Brad Griffis said:
    Jonathan Cormier
    Currently the mods we've had to do to our existing design:
    * Replace DDR_CKE pullup with pulldown
    * Replace DDR_RESETn pullup to DDR_VTT to a pullup to VDDS_DDR

    Looks good.

    I want to update this earlier comment...  I edited my previous post too but wanted to call it out...

    It would be better to have no connection at all on DDR_RESETn.  The JEDEC recommendation on that pin is that it should remain low during power-up.

  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    Jonathan Cormier said:
    For the sleep measurements the DDR2 module is PG1.0 and the DDR3 is PG2.1.

    I just went through a similar issue with another customer.  One item that was very important was to go through this (very arduous!) process:

    http://processors.wiki.ti.com/index.php/Optimizing_AM335x_IO_Power_in_DeepSleep0

    In particular, if there are any floating pins during sleep mode that can result in much higher than expected power consumption.  There were some very low level changes to the I/O and power in PG 2.x where the penalty for a floating pin is actually higher.  So part of this difference could be attributable to floating pins.

    You may also want to go and review a couple items from the errata:

    • Advisory 1.0.6: EXTINTn: Input Function of the EXTINTn Terminal is Inverted
    • Advisory 1.0.14 GMII_SEL and CPSW Related Pad Control Registers: Context of These Registers is Lost During Transitions of PD_PER

    The first advisory related to EXTINTn must be comprehended through board population options.  I suggest "no pull" for both PG1.0 and PG2.1 such that you simply let the external resistor handle the appropriate polarity.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points
    PS. Nothing stood out from your CTT dump. Looked like MPU and PER were in the expected states. That's what makes me think it's either related to standby power of the DDR itself, or perhaps to the I/O configuration I mentioned.
  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    I think we have solved the original suspend/resume issue and I would like to ask that you please start a brand new thread to do any further debug.  In short the main issues were:

    1. DDR_RESET was pulled to the VTT rail which was actually pulling it down in the scenario where VTT is disabled during DS0.  The recommendation here is to have no pull whatsoever on this signal.  That way it will pull low during power up in accordance with JEDEC recommendations, but will still be configured to pull high by software for DS0.
    2. For the 3.2 kernel you needed the patch I posted earlier.
    3. [Unconfirmed] There might be excess current observed in DS0 due to unoptimized I/O settings.

  • 0 in reply to Brad Griffis
    Genius 3575 points

    Brad Griffis said:

    It would be better to have no connection at all on DDR_RESETn.  The JEDEC recommendation on that pin is that it should remain low during power-up.

    Alright thanks for the update.  Here is a capture of the reset signal when there is no pullup.  I'm assuming that little bit of noise is normal and okay?

  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points
    I don't quite understand your screenshot, i.e. that looks like a current calculation that I'm seeing rather than the DDR_RESET. Is this at power-up? It should be low during the voltage ramp and then go high.
  • 0 in reply to Brad Griffis
    Genius 3575 points
    Sorry I should have explained the channels. The red channel is the calculated current. The blue channel is the ddr reset signal. The current drops when entering sleep and the reset signal stays high but seems to gain a good amount of noise.
  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points
    Oh, I see now... Looks like that's only around 10mV of ripple. That's fine. The JEDEC spec considers anything over 1.2V "high" for a 1.5V DDR3 device. So you're not anywhere close to an issue...
  • 0 in reply to Brad Griffis
    Genius 3575 points
    Sounds good. Thanks for all your help.
  • 0 in reply to Jonathan Cormier
    Genius 3575 points
    Created separate issue for minimizing sleep power usage. Posting here for future reference. e2e.ti.com/.../464240
  • 0 in reply to Brad Griffis
    Genius 3575 points

    Brad Griffis said:

    You may also want to go and review a couple items from the errata:

    • Advisory 1.0.6: EXTINTn: Input Function of the EXTINTn Terminal is Inverted
    • Advisory 1.0.14 GMII_SEL and CPSW Related Pad Control Registers: Context of These Registers is Lost During Transitions of PD_PER

    The first advisory related to EXTINTn must be comprehended through board population options.  I suggest "no pull" for both PG1.0 and PG2.1 such that you simply let the external resistor handle the appropriate polarity.

    For the EXTINTn, we have a pullup resistor on our board. Will this cause issues with the active high interrupt?  Also what do you mean by setting to "no pull", is there a conf_ register for this pin?

    Advisory 1.0.14: Is the setting of these registers already handled by the kernel?  Does this errata affect power usage?

  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    Jonathan Cormier said:
    For the EXTINTn, we have a pullup resistor on our board. Will this cause issues with the active high interrupt?  Also what do you mean by setting to "no pull", is there a conf_ register for this pin?

    EXTINTn should be pulled high on PG2.1 silicon.  It is intended to be an active low signal, so in normal operation it should be high and then if an external device wanted to assert an interrupt to the AM335x then that external device could drive EXTINTn low.  In PG1.0, due to the errata, the polarity is inverted, so I would expect the opposite for those devices.

    My comment about configuring "no pull" refers to the fact that you do not change anything in the AM335x software to account for this issue, i.e. the conf_nnmi register can have the same value regardless of whether you're using PG1.0 or PG2.1.  The workaround must reside in the actual hardware (pullup for PG2.1, pulldown for PG1.0).

    Jonathan Cormier said:
    Advisory 1.0.14: Is the setting of these registers already handled by the kernel?  Does this errata affect power usage?

    I think this is inherently handled by the fact that the latest kernels allow you to specify the mux programming for suspend/resume.

  • 0 in reply to Brad Griffis
    Genius 3575 points

    Brad Griffis said:

    EXTINTn should be pulled high on PG2.1 silicon.  It is intended to be an active low signal, so in normal operation it should be high and then if an external device wanted to assert an interrupt to the AM335x then that external device could drive EXTINTn low.  In PG1.0, due to the errata, the polarity is inverted, so I would expect the opposite for those devices.

    My comment about configuring "no pull" refers to the fact that you do not change anything in the AM335x software to account for this issue, i.e. the conf_nnmi register can have the same value regardless of whether you're using PG1.0 or PG2.1.  The workaround must reside in the actual hardware (pullup for PG2.1, pulldown for PG1.0).

    Gotcha, I didn't notice the errata only applied to PG1.0.

    It does appear that our PG1.0 modules still have the pullup.  I'm not sure what problems this would create, "infinite interrupts?"

    Brad Griffis said:

    I think this is inherently handled by the fact that the latest kernels allow you to specify the mux programming for suspend/resume.

    So we should make sure we have a sleep pinmux for each of these pins? 

    The only register that isn't covered by the sleep pinmux logic is the GMII_SEL which hopefully the CPSW driver is handling after resume.

  • 0 in reply to Jonathan Cormier
    TI__Guru*** 125430 points

    Jonathan Cormier said:

    Gotcha, I didn't notice the errata only applied to PG1.0.

    It does appear that our PG1.0 modules still have the pullup.  I'm not sure what problems this would create, "infinite interrupts?"

    I don't think so or you would surely have "felt it".  Is that pin connected to any other device or simply tied off?  I suspect that interrupt is never even enabled by your software.

    Jonathan Cormier said:

    So we should make sure we have a sleep pinmux for each of these pins? 

    The only register that isn't covered by the sleep pinmux logic is the GMII_SEL which hopefully the CPSW driver is handling after resume.

    Correct.  I think you can check this very easily by writing a simple shell script that dumps all those values using devmem2.  You can run it before/after you suspend the device and diff to see if everything was restored properly.

  • 0 in reply to Brad Griffis
    Genius 3575 points

    Brad Griffis said:

    I don't think so or you would surely have "felt it".  Is that pin connected to any other device or simply tied off?  I suspect that interrupt is never even enabled by your software.

    Thats what I figured.  Pretty sure most of our designs the pin isn't connected to anything other than the pull up.

    Brad Griffis said:

    Correct.  I think you can check this very easily by writing a simple shell script that dumps all those values using devmem2.  You can run it before/after you suspend the device and diff to see if everything was restored properly.

    Sure thing. Thanks