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

USB Host/Device idetification

Michi Yama
Guru 10030 points
Other Parts Discussed in Thread: AM3874

Hi,

I have one question.

My customer uses USB OTG module of AM3874 as host. For this reason, they connect USBx_ID pin to Ground. This means AM3874 USB roles as A device (host).

But, in this setting, bit 7 of Device control register changes frequently. Please see the below figure.

I don't know why USB module behave as the above. USBx_ID pin is connected to 0volt.  But USB module

changes the role A device - B device frequently. Is this behavior normal action?

Please advise me.

Best regards,

Michi

  • 0
    TI__Guru**** 170625 points

    Hi Michi,

    Is it possible that you hit the AM387x Silicon Errata (SPRZ345A)?

    Advisory 2.1.9 USB OTG VBUS: SRP on USB "Initial B" Device Not Supported

    Revision(s) Affected: 2.1

    Details: USB OTG PHY (inverted internal SESSEND signal) prevents the use of SRP by the "Initial B" device. In other words, the Host Negotiation Protocol (HNP) part of the   OTG protocol is not affected and the role changing capability during the times the VBUS power remains active is functional. However, during times that the "Initial A" device has removed VBUS power, for power savings, the "Initial B" device would be unable to signal the "Initial A" device to resume power on the VBUS.

    Workaround: Full OTG functionality is not in place and the USB SS should not be used in an OTG environment where role changing is required.

    Best Regards,

    Pavel

  • 0 in reply to Pavel Botev
    Guru 10030 points

    Dear Pavel-san,

    Thank you for your reply. 

    I checked the Advisory 2.1.9 of rev.2.1 errata. I believe this errata shows that SRP is not working on OTG environment.

    But , my customer symptom is occurred without  "Initial B" device. And , in addition, USBx_ID pin is connected to "low" level by pattern.

    I think this condition should make AM3874 USB module become "Initial A" device (Host).  But according to the figure, AM3874's role is

    changing frequently.  Is this normal action? Or strange action by some errata?

    Please let me know.

    Best regards,

    Michi 

  • 0 in reply to Michi Yama
    TI__Guru**** 170625 points

    Hi Michi,

    Fisrt of all, examine the below links:

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

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

    After that, have a look in this thread:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/238460/840999.aspx

    It seems to me that the issue is similar. Are you using EZSDK? If yes, what version?

    Best Regards,

    Pavel

  • 0 in reply to Pavel Botev
    Guru 10030 points

    Dear Pavel-san,

    Thank you for your support..

    My customer uses WINDOWS Embedded OS.

    According to your information,

    1) The default behaviour of OTG controller is as peripheral and once (configured in Host mode) the kernel driver is loaded the behaviour starts to be as expected.

    2) OTG roles can cotrol through USB Mode register by softwre.

    Is my understanding right?

    My customer says, when USB memory is inserted to AM3874 system,  AM3874 OTG module always become to be as peripheral, and after that, OTG module become to be as host. This behaviour is very similar as the above 1).  But in this case,  USB_ID pin is always pulled down.  Is USB_ID pin no influence of OTG role?

    Also I wrote the above, USB_ID pin is always pulled down in my customer system. However, customer's system changes from peripheral to host frequently without any connection of USB device. Can OTG role change bye iddig bit of USB Mode register even thouth USB_ID pin is fixed by hardware? If it is yes, customer symptom is occurred by USB driver automatically?  

    Please advise me again.

    Best regards,

    Michi

  • 0 in reply to Michi Yama
    TI__Guru**** 170625 points

    Michi,

    From hardware perspective, the AM387x USB controller can operate in Host mode (A device). This is what we have in AM387x TRM:

    The Universal Serial Bus Subsystem (USBSS) contains dual USB 2.0 compliant modules. Both modules are configurable as a USB Host, a USB Device or a dual role OTG Host/Device via the On-The-Go (OTG) supplement of the USB 2.0 Specification.

    25.2 Features Supported

    Supports USB Host operations at High Speed (Up to 480 Mb/s), Full Speed (Up to 12 Mb/s) and Low Speed (Up to 1.5Mb/s).

    25.5.1.1 USB Controller Role Assuming Method

    The USB 2.0 controller session starts when one of the following events occurs


    • Firmware assumes it will be operating as the USB Host and sets the DEVCTL[SESSION] bit If the firmware writes to the DEVCTL[SESSION] bit, the USB controller will attempt to determine if it is the 'A-Device', or if it is the 'B-Device' by sensing the resistance on the USBx_ID pin.

    An A-Device is a device with a the Standard A Receptacle or a device with a Micro-A plug inserted into it's receptacle. A B-Device is defined as a device with a (mini-)B receptacle, or a Micro-A/B receptacle with the B end of the plug inserted into it's receptacle.
    If the USB controller determines it is the A-Device it will turn on VBUS and wait until the USBx_VBUSIN pin is >= 4.4V. Assuming that the voltage level of the USBX_VBUSIN is found to within the VBUS Valid range according to the USB 2.0 Specification, the controller will then default to the USB Host and wait for a device to connect to the bus before attempting to enumerate the device.

    If the controller senses it is a B-Device, it will use the Session Request Protocol as defined in the USB OTG Supplement to request a session from the A-Device and default to operating as a USB Device. If desired, firmware can force the USB Controller to act as an A-Device or a B-Device by writing to IDDIG bit in the USB Mode register before it sets the DEVCTL[SESSION] bit. This will override the ID sense value and force the controller to operate as the USB Host or a USB Device.

    25.3.4 USB PHY

    The PHY does not have a built-in charge pump thus an external power source is required to source the 5V VBUS power when operating as a USB Host. The PHY has built in charge detection for device mode and external charge control capability for a host application.

    25.5.1.8.6 FORCE_HOST

    The Force Host test mode enables you to instruct the core to operate in Host mode, regardless of whether it is actually connected to any peripheral; that is, the state of the CID input and the LINESTATE and HOSTDISCON signals are ignored. (While in this mode, the state of the HOSTDISCON signal can be read from the BDEVICE bit in the device control register (DEVCTL)) .
    This mode, which is selected by writing 80h to the TESTMODE register (FORCE_HOST = 1), allows implementation of the USB Test_Force_Enable (USB 2.0 Specification Section 7.1.20). It can also be used for debugging PHY problems in hardware.
    While the FORCE_HOST bit remains set, the core enters the Host mode when the SESSION bit in DEVCTL is set to 1 and remains in the Host mode until the SESSION bit is cleared to 0 even if a connected device is disconnected during the session. The operating speed while in this mode is determined by the FORCE_HS and FORCE_FS bits in the TESTMODE register.

    25.5.4 VBUS Voltage Sourcing Control
    When any of the USB controllers assumes the role of a host, the USB is required to supply a +5V power source to an attached device(s) through the VBUS line. In order to achieve this task, the USB controller requires the use of an external power logic (or charge pump) capable of sourcing 5V power.

    25.9.2.1.22 USB0 Mode Register (USB0MODE)
    The USB mode (USB0MODE) register allows the user a flexibility of controlling the role that the controller assumes. Via the setting of the USB0MODE, the user has the capability of allowing the control to be coming from a register field (USB0MODE[Bit8=iddig]) or from the USB_ID pin which is indirectly controlled by the cable end. If USB0MODE=0, the state of the USB_ID pin controls the role the controller assumes.

    If the requirements stated above are met, the USB hardware should be able to work in host mode as A-device. Then is up to the software. I have no view for the Windows SDK. You can ask in our Windows forum: http://e2e.ti.com/support/embedded/wince/default.aspx

    Other thing you can try is to see if you will have the same strange behaviour (changes the role A device - B device frequently) with our Linux based EZSDK.

    Regards,

    Pavel


  • 0 in reply to Pavel Botev
    Guru 10030 points

    Dear Pavel-san,

    Thank you for your support.

    Our customer has still issue.

    I explained to my customer that USB role can change by uisng iddig bit of USBx Mode Register. And its bit overdrives ID pin. But according to my customer analysis,  iddig bit of USBx Mode register remains set after USB memory is connected to AM3874 normally. Customer said iddig bit always is set after initialization.

    BDEVICE bit of DEVCTL register  is read only bit. And it shows AM3874 roles as BDEVICE. But customer said, iddig bit remains to be set (this means 3874 becomes to be Bdevice) when USB memory connection. The connection is succeeded normally. And BDEVICE bit is cleared (this means 3874 is in A Device).  But iddig bit is set!

    I don't know why 3874 does not become to be BDEVICE even though iddig bit is set.

    Could you give me some advice regarding USB module h/w ?

    Best regards,

    Michi

  • 0 in reply to Michi Yama
    TI__Guru**** 170625 points

    Michi,

    The same problem is described here:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/238460/840999.aspx

    And our USB driver expert answer that Linux PSP should work correct (it is tested):

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/238460/839855.aspx#839855

    So this make me think the problem is in the Windows software that you are using. As I have no view to Windows, I recommended you to ask the question in our windows forum: http://e2e.ti.com/support/embedded/wince/default.aspx - do you have any feedback there?

    Have you try to reproduce the issue with our Linux kernel PSP - linux-2.6.37-psp04.04.00.01?

    Regards,

    Pavel