• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 774 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SYS_CLKREQ not going inactive in retention

Bradley
Prodigy 40 points
Other Parts Discussed in Thread: AM3715, AM3703

Hello,

 

We're using an AM3715 part in our device, and I'm trying to get SYS_CLKREQ to deassert when the device is suspended.

We've got both our boot loader and our WinCE builds able to put the AM3715's core, MPU, and peripheral domains into retention with all other domains in off, and we can successfully wakeup from this state (using GPIO11/EMU0).

The problem is that SYS_CLKREQ is remaining actively driven high by the AM3715 in suspend from both WinCE and our boot loader.

I've confirmed that changing bit 1 of PRM_POLCTRL does result in SYS_CLKREQ switching between driven high and driven low, so the pin is correctly configured for SYS_CLKREQ (with an internal pull down), and being monitored correctly.

 

So, given that all domains are in retention or off, what could be keeping SYS_CLKREQ from going inactive?

 

Here's a dump of the states of interesting registers, saved to internal SRAM just before the WFI instruction which drops the core and MPU into retention:

 

SYS_CLKREQ configuration:

  PRM_CLKSRC_CTRL          0x00000048 (bypass mode, CLKREQ deasserted on SLEEP, RETENTION, or OFF)

  PRM_POLCTRL              0x0000000A

  CONTROL_PADCONF_SYS_32K  0x00080100 (SYS_CLKREQ in upper half, pull down enabled)

 

IDLESTATUS:

  CM_IDLEST_WKUP           0x000002F7

  CM_IDLEST_IVA2           0x00000001

  CM_IDLEST_PLL_IVA2       0x00000000

  CM_IDLEST1_CORE          0xFFFFFFFF

  CM_IDLEST2_CORE          0x0000001F

  CM_IDLEST3_CORE          0x0000000D

  CM_IDLEST_SGX            0x00000001

  CM_IDLEST_CKGEN          0x00000001

  CM_IDLEST2_CKGEN         0x00000000

  CM_IDLEST_DSS            0x00000003

  CM_IDLEST_CAM            0x00000001

  CM_IDLEST_PER            0x0007FFFF

  CM_IDLEST_NEON           0x00000001

  CM_IDLEST_USBHOST        0x00000003

 

WAKEUPSTATUS:

  PM_WKST1_CORE            0x00000000

  PM_WKST3_CORE            0x00000000

  PM_WKST_WKUP             0x00000000

  PM_WKST_PER              0x00000000

  PM_WKST_USBHOST          0x00000000

 

FCLKSTATUS:

  CM_FCLKEN_WKUP           0x00000000

  CM_FCLKEN_IVA2           0x00000000

  CM_FCLKEN1_CORE          0x00000000

  CM_FCLKEN3_CORE          0x00000000

  CM_FCLKEN_SGX            0x00000000

  CM_FCLKEN_DSS            0x00000000

  CM_FCLKEN_CAM            0x00000000

  CM_FCLKEN_PER            0x00000000

  CM_FCLKEN_USBHOST        0x00000000

 

ICLKSTATUS:

  CM_ICLKEN_WKUP           0x00000008

  CM_ICLKEN1_CORE          0x00000000

  CM_ICLKEN3_CORE          0x00000000

  CM_ICLKEN_SGX            0x00000000

  CM_ICLKEN_DSS            0x00000000

  CM_ICLKEN_CAM            0x00000000

  CM_ICLKEN_PER            0x00000000

  CM_ICLKEN_USBHOST        0x00000000

 

AUTOIDLESTATUS:

  CM_AUTOIDLE_WKUP         0x0000002D

  CM_AUTOIDLE_PLL_IVA2     0x00000001

  CM_AUTOIDLE_PLL_MPU      0x00000001

  CM_AUTOIDLE1_CORE        0x7FFFFED8

  CM_AUTOIDLE3_CORE        0x00000004

  CM_AUTOIDLE_PLL          0x00000009

  CM_AUTOIDLE2_PLL         0x00000001

  CM_AUTOIDLE_DSS          0x00000001

  CM_AUTOIDLE_CAM          0x00000001

  CM_AUTOIDLE_PER          0x0007FFFF

  CM_AUTOIDLE_USBHOST      0x00000001

 

CLKSTCTRL:

  CM_CLKSTCTRL_IVA2        0x00000003

  CM_CLKSTCTRL_MPU         0x00000003

  CM_CLKSTCTRL_CORE        0x0000003F

  CM_CLKSTCTRL_SGX         0x00000003

  CM_CLKSTCTRL_DSS         0x00000003

  CM_CLKSTCTRL_CAM         0x00000003

  CM_CLKSTCTRL_PER         0x00000003

  CM_CLKSTCTRL_EMU         0x00000003

  CM_CLKSTCTRL_NEON        0x00000003

  CM_CLKSTCTRL_USBHOST     0x00000003

 

MISC:

  SDRC_POWER_REG           0x000CF8ED

  CONTROL_PADCONF_SAD2D_IDLEACK 0x06003718

  CONTROL_PADCONF_SAD2D_MSTDBY 0x07003718

  CM_CLKOUT_CTRL           0x00000001

  PRM_CLKOUT_CTRL          0x00000000

 

And here are the previous power state registers on resume, showing that everything was off or in retention:

 

  PM_PREPWSTST_MPU     0x45

  PM_PREPWSTST_CORE    0x55

  PM_PREPWSTST_PER     0x05

  PM_PREPWSTST_NEON    0x00

  PM_PREPWSTST_USBHOST 0x00

  PM_PREPWSTST_DSS     0x00

  PM_PREPWSTST_CAM     0x00

  PM_PREPWSTST_SGX     0x00

  PM_PREPWSTST_IVA2    0x00

 

The only clock I've left enabled during suspend is GPIO1 ICLK, in order to allow GPIO11 to wake the CPU.  But I've tried disabling this clock as well, and SYS_CLKREQ still doesn't go inactive (and I am unable to wake the CPU via GPIO11).

 

Any help getting SYS_CLKREQ to go inactive in suspend would be appreciated.

 

                  Brad                     B-)

 

  • 0
    Prodigy 40 points

    Just as a follow up, in case others may benefit from this, I've finally gotten SYS_CLKREQ to go inactive in suspend (retention).

    I believe there are three things I was missing:

    1) All interface clocks must be disabled in the WAKEUP domain.  But as I noted above, doing so prevented the GPIO1 interrupt from waking the MPU.  I got around this by enabling the PRM to generate an interrupt to the MPU on wake-up via the WKUP_EN bit of the PRM_IRQENABLE_MPU register along with setting EN_GPIO1 of the PRM_WKEN_WKUP register (since I'm waking from GPIO1).

    2) The voltage controller must be set to AUTO_RET (only set 1 AUTO_xxx bit at a time!) to enable the VDD1 and VDD2 domains to get put into retention.  I had been running with the voltage processors disabled, not realizing that the voltage domains also had to transition to retention before SYS_CLKREQ would go inactive.

    3) DPLL2 (and all DPLLs, I assume) must be enabled, to allow it to be autoidled when not needed (which is all the time since I'm using an AM3715 part, i.e. no IVA2).  Previously I had manually left DPLL2 in low power stop mode, but this seemed to prevent the VDD1 domain from being able to switch into retention.  Once I enabled DPLL2 (with an arbitrary multiplier and divisor to get 100MHz operation), the autoidle bit (that I had already had set) enabled the DPLL2 to automatically go to low power stop mode, and then VDD1 would finally transition to retention on suspend of our device.

                                    Brad                       B-)

  • 0 in reply to Bradley
    Prodigy 20 points

    I am going to follow this subject but for AM3517EVM. I thnk the flow is following.

    1) No device is selected in the catalog.

    2) Function OEMPowerOff() in power.c is revised to disable all interface clocks in the WAKEUP domain and to set wakeup parameters.

    3) Platform is built.

    Is that right? Thanks for the advice.

  • 0 in reply to Tadashi Samukawa
    Prodigy 20 points

    I'm afraid I probably won't be able to be much help to you.  I was doing my work in our custom OS, rather than in WindowsCE.

    I had disabled all interface AND functional clocks in all domains, since my sole wake-up source was an external pin.  I think you should be able to leave functional clocks enabled in the wake-up domain, AS LONG AS you've confirmed the functional clocks you leave enabled are 32KHz ones (e.g. GPT1 can be set to 32KHz or SYS_CLK ; you'd need it to be set to 32KHz if you want it to be running, and let SYS_CLK stop.

    As mentioned above though, I think the really tricky part is that you must ensure all DPLLs are enabled, with the autoidle bit set to allow them to automatically be idled when not required, rather than manually stopping them (even DPLL2, which should otherwise not be needed in a part without a DSP, yet you must have it enabled with autoidle to get SYS_CLKREQ to go inactive).

    If it's still not working, be sure to try capturing the contents of all the registers I listed above to check for any clocks that may not have gone idle, for whatever reason.  And make sure on resume that the previous power state registers show all domains reaching OFF or RETENTION mode.

                                   Brad                                B-)

  • 0 in reply to Bradley Scott
    Prodigy 20 points

    Thank you for your advice.

    I am going to have a try and make a report later.

  • 0 in reply to Bradley Scott
    Prodigy 90 points

    Hi Brad,

    We are working with AM3703 in our design and the OS is WindowsCE. We achieved ~35mA at 3.7V (Battery) in Standby mode. As per our battery standby lifetime requirement, we need to reduce further and need to achieve <18 mA at 3.7V.

    In our case also we are not able to get SYS_CLKREQ to go inactive (de-assert) in standby mode.

    For our understanding,

     - What is the best Standby mode current/power achieved by you when SYS_CLKREQ inactive mode?

     - Is there any specific GPIO to be used for Wake-up from this mode (SYS_CLKREQ inactive condition) or can we use any GPIO?

    We will try few options from your thread to get SYS_CLKREQ inactive mode and get back with findings.

    Thanks

    Ranjith

  • 0 in reply to Ranjithkumar Muthurajan
    Prodigy 20 points

    Hi Ranjith,

    Using an AM3715, with the OMAP going into full retention (and deasserting SYS_CLKREQ), the OMAP and 256MB SDRAM, current consumption would have been in the 5 to 10 mA range, off a similar 3.7V battery.  Including everything else in our system (e.g. we have a couple microcontrollers for keypad and peripherals that remained powered), our total current draw came in just under 15mA.

    I believe you can wake from full retention using any GPIO on the GPIO1 bank, or using GPTIMER1 (i.e. stuff in the WAKEUP domain).  We used GPIO11.  If you go down further to OFF, then the wake-up pins are further restricted within the GPIO1 bank (we never attempted this).

    Be sure you set-up DPLL2 to autoidle rather than OFF, as this was unintuitive in the case where you don't have the IVA2.  Setting the voltage controllers to AUTO_RET was the other tricky piece of the puzzle that took far too long to figure out.

    Best of luck.

                         Brad             B-)