• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 2052 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.

AM335x USB initialization

Nomo
Guru 16800 points
Other Parts Discussed in Thread: AM3352

Hello,

Please let me know the AM335x USB initialization procedure.
I want to know the preferred procedure to initialize USB as a host mode after DRVVBUS turns to low by detecting VBUS low voltage and by executing procedure described in the following page.
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270060

Which should I do the following procedure as a recovery initialization?

- To write the session bit of by executing "#echo F > /proc/driver/musb_hdrc.x".
- To call the reset function of libusb
- To re-execute the initialization procedure executed at boot up.

Best Regards,

Nomoto

  • 0
    TI__Guru**** 393215 points

    Hi Nomoto-san,

    I will forward this to the USB experts.

  • 0
    TI__Guru**** 167151 points
    Nomoto,

    There is no simple answer to your question since the USB init has quite wide scope in general.
    Please explain what exact issue you are trying to solve then I can provide better support.
    Please also tell what SDK version you use.
  • 0 in reply to Bin Liu
    Guru 16800 points

    Hello Bin-san,

    Thank you for your reply.

    The SDK version is v5.7.
    On my customer's board, the 3G module is connected to the AM3352 USB port.
    AM3352 USB port is set as host.

    At one time, the 3G module doesn't reply for the command from AM3352.
    The module seems to go out of control.

    For the problem, when the transmission failure occurs (e.g. port open failure), my customer recognizes the 3G module goes out of control and tries to recovery (re-initialize) the USB port by the following two procedures.
    1. By executing reset function in libusb.
    2. By accessing to /proc/driver/musb_hdrc.0, the DRVVBUS signal goes to low. And then, VBUS supplied to the 3G module stops.

    I think those procedures need the initialization procedure, and how should I initialize the AM3352 USB port?

    Best Regards,

    Nomoto

     

  • 0 in reply to Nomo
    TI__Guru**** 167151 points

    Nomoto-san,

    Yusuke Nomoto said:
    At one time, the 3G module doesn't reply for the command from AM3352.
    The module seems to go out of control.

    Please provide the log of command 'cat /proc/driver/musb-hdrc.x' at this stage, I'd like to know if MUSB is still in the normal state or not, then we know how to recover.

    Yusuke Nomoto said:
    2. By accessing to /proc/driver/musb_hdrc.0, the DRVVBUS signal goes to low

    Do you mean DRVVBUS is already low by the time accessing /proc/driver/musb_hdrc.0? or accessing /proc/driver/musb_hdrc.0 causes DRVVBUS low?

    How do you know DRVVBUS was low? by probing the pin?

    Basically, if it is only the 3G device failed and MUSB is still normal, we only need to reset the USB bus; but if MUSB is in an abnormal state too, we have to recover MUSB first. I will provide more instructions based on your update.

  • 0 in reply to Bin Liu
    Guru 16800 points

    Hello Bin-san,

     

    Thank you for your reply.

    Bin Liu said:

    Please provide the log of command 'cat /proc/driver/musb-hdrc.x' at this stage, I'd like to know if MUSB is still in the normal state or not, then we know how to recover.

    The log is following.

    cat musb_hdrc.0

    Status: MHDRC, Mode=Host (Power=f0, DevCtl=99) OTG state: a_wait_bcon; inactive

    Options: pio, otg (peripheral+host), [eps=16] Peripheral address: 00 Root port status: 00000100

     

    After AM3352 goes to above condition, by executing "echo b > /proc/driver/musb_hdrc.0", the system can be recovered.

     

    Bin Liu said:

    Do you mean DRVVBUS is already low by the time accessing /proc/driver/musb_hdrc.0? or accessing /proc/driver/musb_hdrc.0 causes DRVVBUS low?

    No, DRVVBUS is not already low by the time accessing /proc/driver/musb_hdrc.0. By accessing /proc/driver/musb_hdrc.0, DRVVBUS goes to low.

     

    When AT port open failure is occurred, my customer knows the system goes to out of control.

     

    Best Regards,

    Nomoto

     

  • 0 in reply to Nomo
    TI__Guru**** 167151 points

    Nomoto-san,

    Yusuke Nomoto said:

    cat musb_hdrc.0

    Status: MHDRC, Mode=Host (Power=f0, DevCtl=99) OTG state: a_wait_bcon; inactive

    It shows the MUSB driver is in a wrong state now.

    Yusuke Nomoto said:
    After AM3352 goes to above condition, by executing "echo b > /proc/driver/musb_hdrc.0", the system can be recovered.

    The 'echo b > ...' command resets MUSB and its driver stack, also resets USB bus to re-enumerate the USB device. So can this 'echo b > ...' command be the valid workaround for recovery for your customer? Or you are seeking for something else?

  • 0 in reply to Bin Liu
    Guru 16800 points

    Ben-san,

    Thank you for your reply.
    I can see the MUSB driver is in a wrong state in the condition showed by the log.
    It seems that 'echo b > ...' command can be the valid workaround for recovery for my customer.

    Best Regards,

    Nomoto

  • 0 in reply to Nomo
    TI__Guru**** 167151 points

    Yusuke Nomoto said:
    It seems that 'echo b > ...' command can be the valid workaround for recovery for my customer.

    That will be great, thanks for confirming.