• State
  • Locked Locked
  • Replies 0 replies
  • Subscribers 97 subscribers
  • Views 163 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.

Getting MUSB to Go Idle

Chris Read
Genius 3345 points
Other Parts Discussed in Thread: SYSCONFIG

I am using the MUSB / OTG USB module in Host mode.

I am trying to get the MUSB module to go idle so the CORE power domain can go idle, and reach the off state.

I have set OTG_SYSCONFIG as Smart-Standby and Smart-Idle. (0x2010), but don't see MUSB going idle (bits 4 & 5 of CM_IDLEST1_CORE are 0's, instead of 1's)

The TRM states in 23.1.3.1.3.2:

• Smart-Idle Mode
When the high-speed USB controller receives an IDLE request from the PRCM module:
– The interface clock USBHS_ICLK is disabled (PRCM register bit PRCM.CM_ICLKEN1_CORE[4]
set to 0) or under automatic control (PRCM register bits PRCM.CM_ICLKEN1_CORE[4] and
PRCM.CM_AUTOIDLE1_CORE[4] both set to 1)
– L4 interface clock idle transitions:
Configured in smart-idle mode (USBOTG.OTG_SYSCONFIG[4:3] SIDLEMODE field = 0x2), the
high-speed USB controller checks for no ongoing activity. The idle acknowledge then is asserted
and the module waits for active system clock gating by the PRCM module (this occurs only when all
peripherals supplied by the same L3 clock domain are also ready for idle).

I have PRCM.CM_ICLKEN1_CORE[4] and PRCM.CM_AUTOIDLE1_CORE[4] both set to 1.  And there is nothing connected to the MUSB's PHY.  However, the MUSB module does not go idle.

  1. Is MUSB guaranteed to get an IDLE request from PRCM with PRCM.CM_ICLKEN1_CORE[4] and PRCM.CM_AUTOIDLE1_CORE[4] both set to 1?
  2. Since I don't have anything connected to the MUSB PHY, does the MUSB USB controller have "no ongoing activity" as referred to above in the TRM?
    1. If so, is the idle acknowledge line getting asserted?
      1. Is there a way to confirm that the MUSB is asserting its idle acknowledge line?
    2. Is there something else that would keep the MUSB from asserting its idle acknowledge line?
  3. If the MUSB is asserting its idle acknowledge line, then what in the MUSB could be holding up the L3 clocks so that idle isn't reached?
    1. Are there ways to check this?
  4. Is getting the MUSB idle a prerequisite for getting it to assert its MSTANDBY line?

Thanks so much,

 

Chris