• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Digital Signal Processors (DSP) » OMAP™ Processors » OMAP-L13x, AM1x and C674x Processors Forum » OMAPL138: missing standard request during USB 2.0 enumeration
Share
OMAP™ Processors
  • Forums
  • Announcements
Options
  • Subscribe via RSS
Resources
  • OMAP-L1x DSP+ARM9™-based Processors Product Folder
  • OMAP3525/30 DSP+ARM Cortex™-A8-based SOCs Product Folder

  • Top OMAPL Wiki Links
  • OMAPL3x Schematic Review Checklist
  • OMAPL13x Boot resources

  • OMAPL Document Resources
  • OMAPL137 Technical reference manual
  • OMAPL138 Technical reference manual
  • OMAPL Boot loader App Notes
  • Forums

    OMAPL138: missing standard request during USB 2.0 enumeration

    This question is answered
    Kiung Chung Wong
    Posted by Kiung Chung Wong
    on Mar 10 2011 19:08 PM
    Expert2090 points

    Hi,

    This is the OMAPL138 eXperimenter Kit. I have changed the OS running on the kit from Linux to VxWorks.

    And I am developing an USB driver (peripheral only) on it. Of course I made reference to the Linux implementation and the L138 USB 2.0 user guide during development.

    I have done the development, and passed the Chapter-9 Tests with the Command Verifier (from usb.org), and the device is also able to enumerate successfully in high speed mode.

    8863.Chapter 9 Tests 2011-01-28.pdf

    But, until recently I have found that although enumeration (high speed mode) is successful, the device actually never receive standard request to get the string descriptor.

    Using software analyzer (USBTrace), I can see the host sending out request to get the string descriptor, but never got it. Other standard requests are working fine. This is the strange part.

    If I disable the high speed, and let the device enumerates in full speed, everything is fine, which means the device is able to receive the request to get the string descriptor. This is the distinct behaviour I see between high speed and full speed.

    There is another problem I am facing using OMAPL138 USB 2.0. I just cannot use the hardware anayzer from Ellisys to look at the USB bus traffic to find out what is actually going on (I have reported this in another post). It is kind of painful without this capability.

    Hopefully someone out there can help me out or shine some light on this.

    rgds,

    kc Wong

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • Ravi B
      Posted by Ravi B
      on Aug 04 2011 06:06 AM
      Expert3710 points

      Wong

      Do you say that the phy configuration done in linux is correct? If so why in linux you have observed the issue.

      I did not understand the fix. Do you say phy configuration is not ok in linux as well. Then how the uImage built by you worked on EVM.

      I did not understand completely. could you explain, what is the root cause where it got fixed.

      Regards

      Ravi B

      If my reply answers your question then please click on the green button "Verify Answer"

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Ravi B
      Posted by Ravi B
      on Aug 04 2011 06:07 AM
      Expert3710 points

      small correction

      If phy configuration is wrong in linux, then how the uImage sent by you worked on my EVM.

      Regards

      Ravi B

      If my reply answers your question then please click on the green button "Verify Answer"

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Kiung Chung Wong
      Posted by Kiung Chung Wong
      on Aug 04 2011 07:08 AM
      Expert2090 points

      Hi Ravi,

      I took TI UBL and added PHY configuration. Only today, when I tried to experiment something else, I put back the TI UBL and noticed this difference. This is the very first code for the USB driver development, never suspect that this is the cause. Partly also because the code is from SPRUFM9H.

      TI UBL + Linux     (OK)

      Modified UBL + Linux (not OK)

      You can take a look at this PHY configuration code which is in the 1st page of this post (05-06-2011).

      Worst thing is full speed works fine with this configuration, and high speed also except for GetDescriptor(string) requests. And all the testing and experiment seem to tell me the HW has problem.

      Not sure you have detailed explaination on this. If yes, hopefully you can share.

      rgds,

      kc Wong

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Ravi B
      Posted by Ravi B
      on Aug 05 2011 00:17 AM
      Expert3710 points

      Wong

      I understood now, you have taken TI-UBL and modified the phy configuration. This modification has leads to this problem and it worked for FS and for HS the string descriptor has caused the problem. This explains the root cause of the problem. Thanks.

      Regards

      Ravi B

      If my reply answers your question then please click on the green button "Verify Answer"

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Kiung Chung Wong
      Posted by Kiung Chung Wong
      on Aug 05 2011 03:29 AM
      Expert2090 points

      Ravi,

      Just to clarify, I did not modify the phy configuration, there was no usb phy configuration in the original UBL.

      I actaully took the sample code for phy configuration from SPRUFM9H, and added into the UBL.

      It turns out to be I should not have followed the configuration shown in SPRUFM9H. The sample configuration shown in SPRUFM9H has caused the GetDescriptor(string) request to fail on eXperimenter Kit.

      You can compare the code in SPRUFM9H and the code in the 1st page of this post.

      I don't know which one is actually causing the problem, either  CFGCHIP2.USB0OTGMODE or CFGCHIP2.USB0PHYCLKMUX .

      My mistake is I should not have just copied the sample code without doubt. And I did post the code and ask for consultation, and nobody pointed out the error.

      Anyway, I still very much appreciate your support.

      rgds,

      kc Wong

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    «23456
    TI E2E™ Community
    • Support Forums
    • Blogs
    • Videos
    • Groups
    • Site Support & Feedback
    • Settings
    TI E2E™ Community Groups
    • TI University Program
    • Make the Switch
    • Microcontroller Projects
    • Motor Drive & Control
    Other Communities
    • Deyisupport
    • Designsomething.org
    • beagleboard.org
    • TI on Element 14
    • TI on TechXchangeSM
    Other Technical & Support Resources
    • WEBENCH® Design Center
    • Product Information Centers
    • Technical Documents
    • TI Design Network
    • TI Technical Articles
    • TI Training

    All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

    Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

    Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
    TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

    TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
    embedded processors, along with software, tools and the industry’s largest sales/support staff.

    © Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
    Trademarks | Privacy Policy | Terms of Use