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.

TM4C123GE6PM: USB Driverlib - Device API layer - tDeviceInfo

Part Number: TM4C123GE6PM

Hello,

I'm trying to figure out how to use the usb driverlib "device api layer" and specifically how to pass the config/interface/endpoint descriptors.  The device info structure seems to NOT include these, but does include the device descriptor which is a uint8 pointer.  So as a first step using this driver layer - what is the expected handling of the config, interface and endpoint descriptors?

  • Just to save anyone time regarding tDeviceInfo here is the source code which doesn't mention the above three missing descriptors that are important for describing the device.

    //*****************************************************************************
    //
    //! This structure is passed to the USB library on a call to USBDCDInit and
    //! provides the library with information about the device that the
    //! application is implementing.  It contains functions pointers for the
    //! various USB event handlers and pointers to each of the standard device
    //! descriptors.
    //
    //*****************************************************************************
    struct tDeviceInfo
    {
        //
        //! A pointer to a structure containing pointers to event handler functions
        //! provided by the client to support the operation of this device.
        //
        const tCustomHandlers * psCallbacks;
    
        //
        //! A pointer to the device descriptor for this device.
        //
        const uint8_t *pui8DeviceDescriptor;
    
        //
        //! A pointer to an array of configuration descriptor pointers.  Each entry
        //! in the array corresponds to one configuration that the device may be
        //! set to use by the USB host.  The number of entries in the array must
        //! match the bNumConfigurations value in the device descriptor
        //! array, \e pui8DeviceDescriptor.
        //
        const tConfigHeader * const *ppsConfigDescriptors;
    
        //
        //! A pointer to the string descriptor array for this device.  This array
        //! must be arranged as follows:
        //!
        //!   [0]   - Standard descriptor containing supported language codes.
        //!
        //!   [1]   - String 1 for the first language listed in descriptor 0.
        //!
        //!   [2]   - String 2 for the first language listed in descriptor 0.
        //!
        //!   ...
        //!
        //!   [n]   - String n for the first language listed in descriptor 0.
        //!
        //!   [n+1] - String 1 for the second language listed in descriptor 0.
        //!
        //!   ...
        //!
        //!   [2n]  - String n for the second language listed in descriptor 0.
        //!
        //!   [2n+1]- String 1 for the third language listed in descriptor 0.
        //!
        //!   ...
        //!
        //!   [3n]  - String n for the third language listed in descriptor 0.
        //!
        //! and so on.
        //
        const uint8_t * const *ppui8StringDescriptors;
    
        //
        //! The total number of descriptors provided in the ppStringDescriptors
        //! array.
        //
        uint32_t ui32NumStringDescriptors;
    };

  • Hi Robert,

      I will forward your post to our USB experts. 

  • Thanks Charles.  It's a bit low level but the more I am going through the standard USB spec and ti docs I need to make sure the MCU can actually feed enough bulk packets into each transaction before I invest in TI silicon and this buffering issue is a big concern.  

    Thanks for the support!

  • Hello Robert,

    Unfortunately the USB low level code is a bit muddled so it can be hard to track through everything. To take a step back here, what sort of interface are you looking to use? Bulk can mean both USB Bulk interface and a bulk endpoint.

    Also from a transaction standpoint, what is the main concern about the bulk packets? The throughput capability, or something more fundamental? The USB stack should meet all USB 2.0 Fullspeed handling requirements.

    Best Regards,

    Ralph Jacobi

  • Hey Ralph,

    So I'm trying to use a USB 2.0 full speed bulk interface which, if I'm correct, will utilize bulk endpoints.  I am not using mass storage, but  raw bulk transfers because I want software to grab the interface and start moving data via bulk transfers in and out of the device.  

    To accomplish this I will be using the API as described in the first post.  I may have figured this out after a few more hours of staring at code, but my question was just the following.

    For the "device api layer" approach, where are the config/interface/endpoint descriptors loaded.  I *may* have figured this out.  It looks like to use this layer you end up loading these descriptors in the init call.  I was confused because they aren't explicitly part of the tDeviceInfo structure that is passed to the init call.  The init call I'm referring to is something like:

    USBDBulkCompositeInit()

    Long story short there are critical descriptors missing from tDeviceInfo which I would have expected to be there, but it looks like they are built separately and loaded separately into the USBDBulkCompositeInit() call.

  • Hi Robert,

    Thanks for explaining the higher level needs here.

    We have a usb_dev_bulk in TivaWare which highlights how to configure a Bulk device interface and it pairs with a bulk example we provide: https://dr-download.ti.com/secure/software-development/software-development-kit-sdk/MD-oCcDwnGrsI/2.2.0.295/SW-USB-win-2.2.0.295.msi

    So that would give you a solid initial starting point for your development.

    Now to go down the next layers of information here:

    You are correct about the USBDBulkInit / USBDBulkCompositeInit call being how to initialize the interface. That is how the USB stack is designed. And passed into that init call has to be a structure that has all the data needed to initialize the interface.

    Long story short there are critical descriptors missing from tDeviceInfo which I would have expected to be there, but it looks like they are built separately and loaded separately into the USBDBulkCompositeInit() call.

    Correct, the descriptors are defined at an application layer and passed into the USB library to make them simple to adjust but more importantly so any adjustments are done at an application level and not at a library level.

    For the usb_dev_bulk example, you'll find all the descriptors inside of the usb_bulk_structs.c file. Any modifications you'd want to make to those descriptors should be done in that file and then you can pass the structure that is defined into the Init call.

    Best Regards,

    Ralph Jacobi