• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 34 subscribers
  • Views 15294 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 Bulk Device Driver / INF as Device 0 in Composite Device

John Collins0
Prodigy 70 points
Other Parts Discussed in Thread: EK-TM4C1294XL

I am using the TM4C123G as a bulk device with DFU options. This uses the Composite Device - as shown in the examples - as a wrapper or container of sorts for the Bulk Device and DFU Device.

The standard DFU driver under the provided windows_drivers folder worked for this setup, but I had to adjust the bulk device driver INF file in order to get Windows to recognize it as the driver for this device. This causes an "unsigned driver" error that is rather painful to ignore in Windows 8 and 10. Is there a signed driver example of the USB Bulk Device as device 0 in a composite device setup? Or is this something that must be customized and signed on our end?

Thank you in advance,

John

  • 0
    TI__Guru**** 244380 points
    Hello John,

    Any change to the driver files would require digital signing to be done. What exactly is the change that has been made.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 70 points
    Amit,

    Thanks for the response.
    The Bulk Device INF file (usb_dev_bulk.inf) is JUST for the bulk device. In order to get it to work when the bulk device is part of a set of composite devices (Bulk and DFU in this case), I had to make changes to the INF file. Under the Manufacturer/Models section of the INF file I changed "USB\VID_1CBE&PID_0003" to "USB\VID_1CBE&PID_000A&MI_00"
    Windows now recognizes it as the correct driver for this bulk device, but it is unsigned.
    I was wondering if there was already an example of the Bulk Device Driver INF for this instance - being used alongside DFU?

    Regards,
    John
  • 0 in reply to John Collins0
    TI__Guru**** 244380 points
    Hello John,

    Check the boot_demo_usb.inf driver files for the same. You can still force the driver files to be accepted in unsigned format on Win 8 but may be not on Win10

    Regards
    Amit
  • 0 in reply to John Collins0
    Genius 4680 points

    John Collins0 said:
    but I had to adjust the bulk device driver INF file in order to get Windows to recognize it as the driver for this device. This causes an "unsigned driver" error that is rather painful to ignore in Windows 8 and 10.


    Since Windows 8, MS has introduced built-in "WinUSB device" class driver (**1),

    WinUSB Device
    https://msdn.microsoft.com/en-us/library/windows/hardware/hh450799(v=vs.85).aspx

    The purpose of a WinUSB device is to enable Windows to load Winusb.sys as the device's function driver without a custom INF file. For a WinUSB device, you are not required to distribute INF files for your device, making the driver installation process simple for end users.


    Adding these features to existing usb_bulk firmware, the device is recognized as "WinUSB device" by Windows.
    1) Get_Descriptor( string ) - "MS OS descriptor" string (index 0xEE)
    2) Vendor requests which claim
    - extended compat ID OS feature descriptor - links the device to in-box Winusb.inf
    - extended properties OS feature descriptor - provides interface GUID

    For the implementation details, refer to "Microsoft OS 1.0 Descriptors Specification", downloaded in this link,
    https://msdn.microsoft.com/en-us/windows/hardware/gg463179

    Using this feature, you'll escape from "unsigned driver" problem ;-)


    (**1) Actually, this mechanism has already existed since WinXP SP2, but in disabled state. Installing MS-genuine winusbcompat.inf/.cat to these Windows versions, it revives.

    MS-official "WinUSB class" driver for XP, Vista and 7
    http://www.microchip.com/forums/m790429.aspx

    Tsuneo

  • 0 in reply to Tsuneo Chinzei
    TI__Guru**** 244380 points
    Hello Tsuneo,

    The ID does not list all device classes. So how can a custom device be integrated, is not clear by the steps-1 and 2?

    Regards
    Amir
  • 0 in reply to Amit Ashara
    Genius 4680 points

    Ah sorry, my words were too short.

    1) Download "Microsoft OS 1.0 Descriptors Specification"
    At the bottom of the "Microsoft OS Descriptors" page (same link as above)
    https://msdn.microsoft.com/en-us/windows/hardware/gg463179
    You'll see MS license agreement column, which has "accept" check box and "download" button.
    Check the box and download the specification.
    - OS_Desc_Ext_Prop.zip is downloaded

    2) There are three files in the ZIP file.
    Here is highlight of each file for WinUSB Device implementation.

    a) OS_Desc_Intro.doc
    "How to Retrieve an OS String Descriptor" section
    "OS String Descriptor" is retrieved by Windows using standard Get_Descriptor( string ) request at index 0xEE.

    "The OS String Descriptor Format" section
    This section describes each field of "OS String Descriptor"
    - qwSignature field must be 'MSFT100' in Unicode.
    - bMS_VendorCode field may be arbitrary number, excluding 0


    b) OS_Desc_CompatID.doc
    "How to Retrieve an Extended Compat ID OS Descriptor" section
    Using above bMS_VendorCode number, Windows put vendor requests to get "extended compat ID OS feature descriptor". In this document, this vendor request is called as GET_MS_DESCRIPTOR

    GET_MS_DESCRIPTOR
      bmRequestType  0xC0
      bRequest       bMS_VendorCode
      wValue         High byte: 0x00, Low byte: interface number, to which this compat ID is assigned
      wIndex         0x04 (extended compat ID OS descriptor)
      wLength        0x10 (length of header part), or the length of entire descriptor

    "Example: WINUSB Compatible ID for a USB 2.0 Non-composite Device" section
    This example gives the exact contents of "extended compat ID OS feature descriptor" for WinUSB Device


    c) OS_Desc_Ext_Prop.doc
    "How to Retrieve an Extended Properties OS Descriptor"
    Using similar vendor request, another descriptor is retrieved by Windows.

    GET_MS_DESCRIPTOR
      bmRequestType  0xC1  // <-- different from above one (**1)
      bRequest       bMS_VendorCode
      wValue         High byte: 0x00, Low byte: interface number, to which this compat ID is assigned
      wIndex         0x05 (extended properties OS descriptor)
      wLength        0x0A (length of header part), or the length of entire descriptor

    "Appendix C: Extended Properties Descriptor for Device Interface GUID" section
    This example gives the exact contents of the descriptor for the interface GUID of WinUSB Device


    That' all ;-)


    (**1)
    USB 3.0 driver of Renesas Electronics (or NEC) on Windows XP, Vista and 7 wrongly puts bmRequestType: 0xC0 for this request. As workaround of this driver bug, your device may accept both of bmRequestType, 0xC0 and 0xC1 for this request.


    Tsuneo

  • 0 in reply to Tsuneo Chinzei
    Genius 4680 points

    Hi John,

    I'm still investigating on your case, composite device of WinUSB + DFU.
    I posted WinUSB Device modification for plain usb_dev_bulk example (single interface).

    "WinUSB Device" implementation for Tivaware
    https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/481401


    For composite device, a little more elaboration is required,
    - compatID for each interface should be reported (including no combatID).

    And then, DFU implementation on Tivaware is examined.
    There are two INF files for DFU, ROM bootloader (boot_demo_usb.inf) and firmware bootloader (boot_usb.inf).
    Both are almost identical in its function and implementation, except for trivial difference. These are almost standard WinUSB INF file. Major deviation is that they copy lmusbdll(64).dll/.lib, lmdfu(64).dll/.lib to the system directories.

    Next, I examined lmusbdll.dll and lmdfu.dll
    These DLLs are user-mode one, not for kernel mode (Confirmed using Dependency Walker and IDA pro). No need to be installed into system directories. They may be distributed in the folder of the DFU PC application.

    In conclusion, TivaWare DFU also can be installed as a WinUSB Device, without any INF file after Win8 (maybe).

    To verify this speculation, I'm modifying boot_usb (dk-tm4c123g) example for WinUSB Device. But my free time has been almost expired in this week. Will report on the next week.

    Tsuneo

  • 0 in reply to Tsuneo Chinzei
    Genius 4680 points

    Hi John,

    Here is source of the composite device, usb_dev_bulk + DFU-rt with WinUSB Device.
    Both of interfaces are installed automatically at plug-in without manual driver assignment. No INF file is required on installation.

    WinUSB_Device_bulk_DFU.zip

    - TivaWare_C_Series-2.1.2.111
    - Tested on DK-TM4C129X, Keil v5.17
    - on Windows 8, 8.1, 10 (x86 and x64)
    - also on Windows 7 (x86 and x64) with winusbcompat.inf/.cat

    To run this modification,
    - Copy \dk-tm4c129x\usb_dev_bulk folder on the same place (click, CTRL-C, CTRL-V) and rename it.
    - Move files in above zip into this copied folder.
    - Run usb_dev_bulk project on your favorite IDE, unregister these files from the project
        usb_dev_bulk.c
        usb_bulk_structs.c
    - Register these files, instead
        usb_bulk_DFU_structs.c
        usb_dev_bulk_DFU.c
        usbdenum_mod3.c
        usbdMSdesc2.c
    - build and download to the board

    - plug the board into Windows PC
    A device installation gauge appears on the bottom bar of PC screen.
    It takes 20-30 seconds to finish installation.
    On the Device Manager, two instances of "Generic Bulk Device+DFU" appear under "Universal Serial Bus Device"

    - test the device using these utilities
      usb_bulk_example.exe
      "dfuprog -e"
    ( you may need to copy lmusbdll.dll and lmdfu.dll into the save folder of above EXE )


    To make sure that the device should work with any VID/PID, modify VID/PID of the device

    usb_bulk_DFU_structs.c

tUSBDCompositeDevice g_sCompDevice =
{
    //
    // Stellaris VID.
    //
    0xFF0F,   // USB_VID_TI_1CBE,

    //
    // Stellaris PID for composite HID/DFU device.
    //
    0xFFFC,   // USB_PID_COMP_HID_DFU,


    Enjoy!

    Tsuneo

  • 0 in reply to Tsuneo Chinzei
    Prodigy 70 points

    Should I expect different results if I ran this under the TivaWare_C_Series-2.1.0.12573 example version?

    It connects as an "Unknown Device" and will not let me do anything with it.

    I'm installing the v2.1.2.111 now, with all the compiler dependencies that are needed for that. I'll see if I get different results this way.

    I tried plugging in the changes I noticed from this example to my existing project (using the TivaWare libraries from v2.1.0.12573). I got everything to load up properly, but the devices show up as two WinUsb Devices under the Universal Serial Bus Devices (This seems to be Windows 7 specific). I can't connect to the USB handle from my interface software on the PC and the dfuprog -e doesn't show anything either.

  • 0 in reply to Tsuneo Chinzei
    Prodigy 70 points

    Thanks for this! After updating the ARM Compiler to v5.2 and using the TivaWare C Series v2.1.2.111 files, I was able to get the example working. From here, I was able to add it to one of our existing builds. We are testing this out now to see if it will work for our solution.

    Regards,

    John

  • 0 in reply to Tsuneo Chinzei
    Intellectual 800 points
    Tsuneo,

    Thanks for the great post.
    I was able to hack your demo to run on the 1294xl board.
    It does enumerate just fine and doesn't care what PID/VID I use. So, it is clearly installing using "In the Box" infs.

    From what I have read, this approach should work on Win8, Win10 and Win7 if the proper winusbcompat.inf/.cat is installed on Win7

    I looked into the generic devices supported. USBSer is not one of the known MS OS Descriptor types. From there, I looked at your code in a bit more detail.

    It looks like you are referencing in-the-box drivers by specifying a GUID. I assume that the same approach would work for USB Serial. However, where do I find the appropriate GUID to include? Or asked another way, is there a way to get a list of in-the-box drivers and their GUIDs?

    Thanks

    Dan
  • 0 in reply to Tsuneo Chinzei
    Prodigy 50 points

    I am currently attempting to incorporate your solution into an existing project we have that uses 3 separate interface, only one of which supports the MS OS Descriptor, through the USB Bulk device type, the others use the standard CDC and HID interfaces.

    I've pulled in your usbdenum_mod3.c file into the project and verified that the MSOSdescHandleStringRequest() routine is getting called, but i never receive a GET_DESCRIPTOR request form the Windows host at string index 0xEE.

    This project is linked to an unmodified version of usblib.lib. Is it possible that the enumeration code in the usblib.lib is stalling the string request at offset 0xEE before it is able to be processed by the modified version of the USBDReadAndDispatchRequest() routine in usbdenum_mod3.c? Any other explanation for why I am not seeing the Get Descriptor request at index 0xEE?

    thanks for any help you can provide!

    Kashif

  • 0 in reply to Tsuneo Chinzei
    Intellectual 800 points

    Tsuneo,

    I am having trouble getting this to work on the ek-tm4c1294xl board.

    I changed the device definitions in IAR and the device type, commended out all of the uart and LCD calls.  I just want to be able to publish the DFU device.

    I did have to add a cast to get get it to compile properly:

               if ( MSOSdescHandleStringRequest( psUSBRequest,

                                                 &(psUSBControl->pui8EP0Data),

                                                  (uint32_t*) (&(psUSBControl->ui32EP0DataRemain) ) )  )

    Without it, I got an error that a volatile uint32_t was being passed.   

    The code runs and enumerates.

    USB Device Viewer reports an error:

    ===>Device Descriptor<===
    bLength: 0x12
    bDescriptorType: 0x01
    bcdUSB: 0x0200
    bDeviceClass: 0xEF
    *!*ERROR: Multi-interface Function code 239 used for device with no IAD descriptors
    bDeviceSubClass: 0x02
    *!*ERROR: bDeviceSubClass of 2 is invalid
    bDeviceProtocol: 0x01
    bMaxPacketSize0: 0x40 = (64) Bytes
    idVendor: 0x1CBE = Texas Instruments - Stellaris
    idProduct: 0x0233
    bcdDevice: 0x0100
    iManufacturer: 0x01
    English (United States) "Texas Instruments"
    iProduct: 0x02
    English (United States) "Generic Bulk Device+DFU"
    iSerialNumber: 0x03
    English (United States) "12345678"

    The DFU function appears to be set up correctly:

    ===>Interface Descriptor<===
    bLength: 0x09
    bDescriptorType: 0x04
    bInterfaceNumber: 0x01
    bAlternateSetting: 0x00
    bNumEndpoints: 0x00
    bInterfaceClass: 0xFE -> This is an Application Specific USB Device Interface Class
    -> This is a Device Firmware Application Specific USB Device Interface Class
    bInterfaceSubClass: 0x01
    bInterfaceProtocol: 0x01
    iInterface: 0x00

    ===>HID Descriptor<===
    bLength: 0x09
    bDescriptorType: 0x21
    bcdHID: 0xFF0F
    bCountryCode: 0xFF
    bNumDescriptors: 0x00

    I tried running LMFlash Programmer.  It doesn't see my device.  I also tried dfuprog.exe with the same results.  (I did have to recompile dfuprog as I couldn't find a precompiled image).

    If I erase the chip and reset, both programs see the Rom version of the boot DFU just fine.  I can program them if I first erase the vector table.  

    I am using 2.1.2.111

    I also went through the process of uninstalling all failed devices and removing windows\inf\oemxxx files with the Pid/Vid.  (I used one of my registered PIDs in the  example above.  - 0x0233)

    Any suggestions?

  • 0 in reply to Kashif Hasan
    Genius 4680 points
    Sorry for too late answer,

    I've pulled in your usbdenum_mod3.c file into the project and verified that the MSOSdescHandleStringRequest() routine is getting called, but i never receive a GET_DESCRIPTOR request form the Windows host at string index 0xEE.


    Windows issue Get_Descriptor(String, 0xEE) to every USB device in enumeration. But it occurs just once, at the first plug in of the USB device to a PC. If you wouldn't see this request in enumeration, it means that your device (VID/PID) should have been already "registered" on the registry.

    Uninstall your device on the Device Manager, and you'll see this request again.

    Tsuneo
  • 0 in reply to Tsuneo Chinzei
    Intellectual 800 points

    Tsuneo,

    Is it possible to create a composite CDC serial port with DFU that does not require an inf?  

    I have my composite 3 port serial working.  I am using the strategy you show for bulk, but it will not install the DFU correctly. 

    Device USB\VID_1CBE&PID_0234&MI_06\9&2524e4fc&2&0006 was configured.

    Driver Name: null
    Class Guid: {00000000-0000-0000-0000-000000000000}
    Driver Date:
    Driver Version:
    Driver Provider:
    Driver Section:
    Driver Rank: 0x0
    Matching Device Id:
    Outranked Drivers:
    Device Updated: false
    Parent Device: USB\VID_1CBE&PID_0234\00000002

    The parent device is CDC and needs usbser.. The example DFU seems to use Winusb 

    I see that usbdMSdesc2.c has the GUID for the TI Bulk Device.  I assume I need to change that to CDC Serial GUID... 

    I am not asking you to figure out my problem, but would appreciate any direction you can give me on strategy and where to look.

    Thanks


    Dan

  • 0 in reply to Dan Beadle
    Prodigy 200 points

    Hi,

    I have been working with the example usbserialdevice.  When I use this example with my development board using a TM4C129NDCPT, it works great.  The troubles I'm having is migrating that understanding to my other projects.  When the USB installs from my custom project, I get an error in my device manager "A request for the USB device descriptor failed."  Additionally, I noticed that in my details under the device, under device instance path, my VID and serial number are not what are in my custom project.

    I haven't really changed much in the code.  I just have referenced USBCDCD.c, USBCDCD.h and I am pretty sure I have set all my pins appropriately in my pin setup,

    MAP_SysCtlUSBPLLEnable();
    //
    // Enable pin PB1 for USB0 USB0VBUS
    //
    MAP_GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_1);

    //
    // Enable pin PL6 for USB0 USB0DP
    //
    MAP_GPIOPinTypeUSBAnalog(GPIO_PORTL_BASE, GPIO_PIN_6);

    //
    // Enable pin PB0 for USB0 USB0ID
    //
    MAP_GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0);

    //
    // Enable pin PL7 for USB0 USB0DM
    //
    MAP_GPIOPinTypeUSBAnalog(GPIO_PORTL_BASE, GPIO_PIN_7);

    I'm sure I'm just missing one key detail.  

    Steve

  • 0 in reply to Stephen Jackson
    Prodigy 200 points
    Also I get nothing detected on option board when loading the program.