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.

PROCESSOR-SDK-AM335X: Looking for ANY USB Doc

Part Number: PROCESSOR-SDK-AM335X

Hello,

As typical, useful doc is nowhere to be found.

I am attempting to research running a USB host on a BBB, using everything in pdk_am335x_1_0_17  (or is it processor_sdk_rtos_am335x_6_03_00_106...? I installed what I was told, and have two folders.)

I tried looking for examples, and there are several of them.  Many look like devices, not hosts.  So I tried to consult the doc.

In C:\ti\processor_sdk_rtos_am335x_6_03_00_106\docs  ever PDF just points you to a web page.

All "USB_HostMsc" says is "OMAPL13 LCDK host and device examples share the same USB port. Need OTG cable for EVM with OTG port to work in host mode."  Not very informative about what the example is and does.

Well, I imported it anyway.  It appears to be an MSC, I assume running as a host, due to the project name.

It begins with a call to USB_open(...)   A search gives me section 6.3.  and says it can open as MSC, Audio, or bulk...

Not a SINGLE actual description of the function call is described.  Like a real API document...?

Further on, there is a call to USBHMSCDriveOpen.  That doesn't show up ANYWHERE in any search.

Looking in usb_drv.h, there are a handful of functions totally lacking any any details.  For example, USB_open requires a pointer to a USB_params, which only has weak comments.  The USB_MODE member only lists two enums with the word "HOST" in it: MSC and AUDIO...   Are there no others?  The member "usbCLassData has the entirely lacking description "pointer to USB Class data".  Since it's a "void *" there is no way to know what type of data that is.

Is there any real doc on using the USB libraries?  Something comprehensive like spru523 and spru524?  Something that explains how it works beyond the limited examples?  Where the system acts as a host to a typical bulk device which uses our custom messages?

  • (GAWD I HATE THIS SITE...  IT REFRESHED AND EATS THINGS I TYPE.  MAKING ME COMPOSE THESE ALL OVER AGAIN.)

    So... here I go AGAIN...

    I saw that link.  I need information on lower level APIs.  Our device is not simply a HOST Mass Storage Class.

    This Support Library seems to only know how to do things for a very limited range of classes. (One host class, and 3 device classes).  Out device is actually something beyond that.

    There is no actual API doc anywhere I can find.

    I refer you to document "spmu020o" as an example of what an API doc should look like, from a different product line of TI's.  Back 10 years ago...

  • The PDK has API documentation on every low level driver including USB. Please look at pdk_am335x_1_0_17\packages\API_Documentation.html -> USB LLD -> Modules -> Driver Function API.

    Hope this is helpful.

    Regards,

    Jianzhong

  • So it's NOT the folder actually named "docs"  which is located in C:\ti\processor_sdk_rtos_am335x_6_03_00_106\docs

    Because all that one is, is a handful of PDFs telling you to go online.  Which is what I did.

    I see this one... it's just another collection of useless DOXYGEN generated material that:

    • Has no overview, introduction or explanation (unlike spru524, spmu298, Starterware UG, etc...)
    • Is bereft of any examples
    • Is not searchable
    • requires you to know what source file contains what you are looking for...

    The reference file "...ti/drv/usb/docs/doxygen/html/group___driver_function_a_p_i.html"   Is just another list of 75+ functions that have no overview.  And has links to poorly described functions.

    This material has ZERO instructional value.  It's written like notes the developers wrote to themselves.

    Now I know why the original team refused to use any of these libraries, and instead choose to migrate all the bare metal code they could find into this 450,000+ line project.  It's because that has REAL documentation (starting with spruh73).

  • Thank you for your feedback. I appreciated it very much. It is very helpful for us to improve our documentation in future.

    Best regards,

    Jianzhong

  • My question STILL stands.  

    Does TI have any USELFUL doc, or any intention of writing ANY useful doc??

    i.e.

    In function "USBHCDInit(...)"

    \param pvPool is a pointer to the data to use as a memory pool for this controller.

    ... what is it?   Wat is it used for?  What size should it be??

    In the function "USBHCDControlTransfer(...)"

    //! \param ulDevAddress is the address of the device for this request.

    Is USELESS.   What is ulDeviceAddress??  Where does this come from?  Is it a hardware register?  An address to WHAT??

    The ONLY USB Host example is MSC host driver. And uses builtin functions JUST for MSC device classes.  What if I need to use functions that are LOWER LEVEL than these examples that have wrapped functions.  Where the doc on those?  

    Because the header file comments, as shown above, don't explain anything.

    Can you see how this is useless to someone trying to learn the material??

  • Thanks for sharing your experience. It must be very frustrating. I agree that there are gaps in the documentation for the low level drivers. Unfortunately at this point, there is no plan to update the driver documentation for AM335x PDK. 

    Best regards,

    Jianzhong

  • How about updating and/or supporting the TRM itself??

    Because SPRUH73 (rev q) is missing critical information.  Not only cross referencing it to old example code, but also there are portions of the doc refer to itself which are missing information...

    Old and new example code reference memory locations (registers) which map to USB1, USB1_PHY, and USB1_CORE, based on section 2.2 of the spruh73.

    Section 16.4 provides descriptions of USB1 and USB1_PHY register offsets.  BUT NOTHING for USB1_CORE  (or USB0_CORE either).

    Section 16.2.5 describes indexed and non-indexed access to endpoint status registers located in memory map ranges ...1C00 and ...1D00.  Again...  these are memory locations in USB1_CORE which are NOT DOCUMENTED.

    So even if I were to disregard support for your libraries, the TRM itself is inadequate to attempt to write my own.

    Does TI plan to support their customers??