• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 504 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.

VUSB3V1 Non-Powerdown and Then USB OTG Doesn't Work

Chris Read
Genius 3345 points
Other Parts Discussed in Thread: TPS65950, OMAP3530

We have a design (OMAP3530 & TPS65950) that ties ADCIN5 to a voltage that is always on.  The possible current is small, a maximum of ~18 microamps, but according to the TRM, a DC voltage on ADCIN5 isn't OK if VUSB3V1 is off.

So I modified the driver code to leave VUSB3V1 on, but now after powering the PHY and MUSB back on, the USB device isn't recognized anymore.

 

Is there something I need to do to get it to recognize the device if VUSB3V1 is left on?

 

Alternatively, can I turn off VUSB3V1 if ADCIN is non-zero, but quite current limited?

 

Thanks!

  • 0
    Genius 3345 points

    After further investigation the MUSB driver is indicating a VBUS error after powering down the MUSB and PHY and powering it backup -- but only if the VUSB3V1 is kept on.  The driver seems to be trying to retry, but never gets further.  The following is output by the driver:

    VBUS_ERROR in a_wait_bcon (91, <VBusValid), retry #1, port1 00000100

    But since the MUSB registers aren't public, I'm not sure how to proceed.

  • 0 in reply to Chris Read
    TI__Genius 15100 points

    Hi Chris,

    I dont know why you would see this behavior. I dont know MUSB details and the protocol. Do you know if MUSB expects the PHY 3.1V to be off when MUSB is off. This seems to be the case but for MUSB to have this condition is unusual. 

    Can you ask this question and describe your observation on the OMAP support forum. You may get some details about MUSB operation.

    Sorry that I couldnt help in this.

     

    Regards,

    Gandhar.

     

  • 0 in reply to Gandhar Dighe
    Genius 3345 points

    I put some instrumentation in the PHY wakeup code and found the following differences in the TPS65950's PHY registers between the working version and the broken version:

    Register Name Register Address Value when Working Value When Broken
    FUNC_CTRL 0x04 0x44 or 0x45 0x40 or 0x45
    OTG_CTRL 0x0a 0x26 or 0x07 0x04
    USB_INT_LATCH 0x14 0x0f 0x03
    DEBUG 0x15 0x0c 0x00

    The USB_INT_LATCH register indicates that SESSEND_LATCH and SESS_VALID_LATCH are not set in the not working case, but are set in the working case.  The instrumentation I put into the code indicates that MUSB gets a SessEnd when working, but only the VbusValid when not working.  This seems consistent.

    Any reason why VUSB3V1 being forced on (by setting VUSB3V1_REMAP to 0xee) would cause the SESSEND_LATCH and SESSVALID_ LATCH to not get set?

    Thanks for looking at this...

    - Chris

  • 0 in reply to Chris Read
    TI__Genius 15100 points

    Hi,

    Solution is on the OMAP forum page - 

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/87001/300534.aspx#300534 

     

    Regards,

    Gandhar.