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.

"WinUSB Device" implementation for Tivaware

Other Parts Discussed in Thread: EK-TM4C1294XL, EK-TM4C123GXL

Windows 8 and later versions have introduced built-in "WinUSB device" class driver.

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.


Here is "WinUSB Device" implementation on TivaWare usb_dev_bulk example.

WinUSB_Device_mod2.zip

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

[revison2]
- The implementation of MS OS descs are moved into separated file, to make maintenance easy

To run this modification on your side,
- copy usb_dev_bulk example folder of your board at the same place (click, CTRL-C, CTRL-V) and rename the folder.
- move the files in the zip to the copied usb_dev_bulk folder
- integrate these files into the IDE project

  usbdbulk_mod2.c
  usbdenum_mod2.c
  usbdMSdesc.c

To make the device "new" one for your PC, modify VID/PID of the device

usb_bulk_structs.c

tUSBDBulkDevice g_sBulkDevice =
{
    USB_VID_TI_1CBE,    // <--- ex, 0xFF00
    USB_PID_BULK,       // <--- ex, 0x1234


- build and download to the board

- plug the board into Windows PC (8, 8.1 or 10)
A device installation gauge appears on the bottom bar of PC screen.
It takes 20-30 seconds to finish installation.

- On Device Manager, the board appears as Generic Bulk Device under Universal Serial Bus Device

- Optionally, you may run usb_bulk_example PC application (in \TivaWare_C_Series-2.1.2.111\tools folder) to make sure the board works.
Even on the new VID/PID, this PC app can catch the board, because the modified firmware returns right interface GUID to PC.


The outline of "WinUSB Device" implementation was discussed on this topic,
https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/480438/1732536#1732536

I hope TI would integrate this feature into the next Tivaware version.


(**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. Written in this post,

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


Tsuneo

  • Hello Tsuneo,

    There was no zip file attached?

    Regards
    Amit
  • yah, failed on the first post, but now on there ;-)

    Tsuneo
  • Hello Tsuneo,

    Another modification that you have suggested is as follows

    USB_VID_TI_1CBE, // <--- ex, 0xFF00
    USB_PID_BULK, // <--- ex, 0x1234

    Are these values fixed?

    Regards
    Amit
  • Another modification that you have suggested is as follows

    USB_VID_TI_1CBE, // <--- ex, 0xFF00
    USB_PID_BULK, // <--- ex, 0x1234

    Are these values fixed?

    Any VID/PID will do, unless it has already occupied on your PC.
    Of course, above VID/PID isn't official one. Keep the device on your desktop just for testing.

    Windows query MS OS string descriptor (string index 0xEE) to every USB2.0 device (bcdUSB field of Device descriptor is 0x200), when its VID/PID isn't registered on the registry, ie. just at the first plug in. When the device returns correct MS OS string descriptor, Windows claim Extended Compat ID OS Descriptor using specific vendor requests. According to returned compatible ID, Windows assign PC built-in driver automatically. Windows may put another vendor request, to fill the registry for the claimed USB class.

    Tsuneo
  • Hello Tsuneo,

    In the existing TivaWare all examples uses VID of TI (0x1CBE) and different PID's based on which example may be running. And if a failed instance of the driver has been already executed, then would the new method still work?

    Regards
    Amit
  • Hello Tsuneo,

    Also on a slightly different note, the TivaWare USB drivers do not seem to work on Win10. Is this issue of TivaWare drivers not being recognized on Win10 machines also from the same cause

    "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."

    If that is the case then can it be disabled somehow?

    Regards
    Amit
  • And if a failed instance of the driver has been already executed, then would the new method still work?

    It depends on the stage at which driver installation failed.

    Here is rough sketch of device start up after plug in.

    By early Get_Descriptors at device plug in, Windows know the VID/PID and configuration of the device. Based on VID/PID (and interface number, for composite device), Windows generate hardware ID (VID/PID+interface) for the device. Also compatible ID (class ID) is determined using device/interface class triad.

    First, Windows scans registry (Enum\USB) for the hardware ID. If there would be matched VID/PID/interface on the registry, no installation occurs. Windows assign the PC driver, recorded on the registry, to the device.

    When no registry entry is found, Windows searches for appropriate driver in Driver Store and inf directory based on the hardware ID and compatible ID. If it finds a couple of matched ones, Windows compare priority of the drivers. (signed > built-in > no signed)

    When no driver is found, Windows ask new driver to users.
    If user cancels installation at this point, no driver instance is made on the registry, in principle. For composite device, however, partial installation may occur.

    Finally, when one driver is selected, Windows registers it on the registry. The driver begins its own initialization, communicating with the device. If the driver would fail its initialization, Code 10 error is reported and results in failed instance on the Device Manager.

    Once a driver is registered on the registry for the device, no MS OS descriptor query occurs, even if the driver would fail the last initialization. Such an instance should be uninstalled on the Device Manager or using utility like USBDeview.

    Tsuneo
  • Also on a slightly different note, the TivaWare USB drivers do not seem to work on Win10. Is this issue of TivaWare drivers not being recognized on Win10 machines also from the same cause.

    I'm not sure which TivaWare driver(s), please specify.

    To trace installation failure, SetupAPI.dev(.log) in \Windows\INF folder is helpful.
    Compare this log of Windows10 failed case with Win8/8.1 successful one. At which line, the logs become different? This log is verbose, but comparing both cases, you'll find quickly exact culprit why installation goes out of rail.

    Before plugin the device, delete (or rename) SetupAPI.dev.log. At the start of device installation, new one is created by Windows. In this way, you'll get clean log, just related to the installation.


    Windows 10 has introduced built-in INF file (usbser.inf) for usbser.sys.
    If the installation problem would occur on CDC device, it may be related to this change.

    Tsuneo
  • Hello Tsuneo,

    Thanks for the detailed explanation. The ICDI and CDC fail install on Win 10 machines. Now I can at least look at some of the paths on a Win10 machine and check.

    Regards
    Amit
  • Hi Amit,

    The ICDI and CDC fail install on Win 10 machines.


    Downloaded ICDI driver newly from this site:
    www.ti.com/.../stellaris_icdi_drivers
    SW-ICDI-DRIVERS:Stellaris ICDI Drivers

    The valid term of the cat files are expired.


    Tested on Win 8.1 / 10, x86 and x64 (kept in clean installed - maintained on VMWare)

    On the x86 platforms, every plug-in installation reports "Not digitally signed"

         dvi:           Rank         - 0x80ff0001
         dvi:           Signer Score - Not digitally signed
    

    On the x64 platforms, installation failed.

    Double clicking on the .cat files, you'll see the status of the certification by the .cat file.
    All of them are expired.

    - The major certificate
     Publisher: <StellarisWare Test Certificate> - just for test on development

    - Sub certificate
     Publisher: VeriSign Time Stamping Services Signer - G2
     valid in: 2007/06/15 - 2012/06/15


    Tsuneo

  • Greetings Tsuneo,

    Thank you and BRAVO for your (usual) most terrific work! (here & elsewhere!)

    it would appear - "Dog ate vendor's .cat homework." (good grief!)
  • Hello Tsuneo,

    What was the error message in Device Manager when you tried to install the drivers manually. I remember seeing an "Error 10" code. Did you see something same?

    Regards
    Amit
  • Amit,

    I believe you have trouble of version control on TI server.

    1) The digital signing for .cat files are out of date on all of the ICDI drivers, distributed in this web page.
    www.ti.com/.../stellaris_icdi_drivers

    2) All of catalog (.cat) files in windows_drivers folder doesn't have digital sign yet, in Recent TivaWare releases.
    - TivaWare_C_Series-2.1.2.111  - not signed yet
    - TivaWare_C_Series-2.1.1.71   - not signed yet

    On the other hand, these former releases have validly-signed .cat files.
    - TivaWare_C_Series-2.1.0.12573 - OK
    - TivaWare_C_Series-2.0.1.11577 - OK

    The status of digital sign is displayed by clicking on the .cat file on Windows PC.
    Please check them.


    The trouble on Windows10 should be touched after fixing this trouble first.
    Unless we would examine the same version, our discussion should diverge.

    Tsuneo

  • Hello Tsuneo,

    So let us fix the first set of issues of the digital signature mismatch and check if it installs correctly on Win10 machines

    Regards
    Amit
  • Hello Tsuneo,

    Shortly after sending the last post, I have realized (and in a great measure to your support and guidance), why driver signatures did fail during build. Got to work on it fast now to begin some testing with the build machine.

    Regards
    Amit
  • Hello Tsuneo,

    Just as we suspected the issue was with the CA certificate that was used for the cat files. Fixed the same and the new driver files have started working on a Win10 machines where they were failing.

    Regards
    Amit
  • Hi Amit,

    Sorry for my late response,
    glad to hear your problem has solved ;-)


    Back to the original theme of this topic,
    I've revised / re-posted the implementation at the first post.
    - MS OS desc implementation was separated into new .c/.h for maintenance and extension.
    - Modifications to the original files are minimized.
    Also, tested on ek-tm4c123gxl, ek-tm4c1294xl, dk-tm4c123g and dk-tm4c129x

    In another topic, I posted source of composite device, usb_dev_bulk + DFU-rt, with WinUSB Device
    e2e.ti.com/.../1741636

    Tsuneo
  • Hello Tsuneo

    Yes, I did see the other post. The next question is about the code base driver files for Linux and existing Win7 and earlier platforms, but before I frame my question, I will have to study the updated example.

    Regards
    Amit
  • Hi Tsuneo,

    First, THANK YOU for sharing your wonderful code and expertise -- this has been fantastic.  

    I was able to get this working on my device, but there was a small issue I ran into -- namely, my device showed up in device manager with the proper drivers, but my client program that I wrote to communicate with the device could not find it.  After digging into it a bit, I found a very helpful note on this page () that does a good job of explaining what was going on.  When returning the DeviceInterfaceGUID request, LibUsbDotNet (and several other libraries?) seem hardcoded to look ONLY for DeviceInterfaceGUIDs.  

    Because of this fault in those libraries, when your patch returned the DeviceInterfaceGUID property, it wasn't being enumerated by my libraries.  

    I (clumsily) modified your code to return a DeviceInterfaceGUIDs response instead (using USB_EX_PROPERTY_REG_MULTI_SZ instead of USB_EX_PROPERTY_REG_SZ), and that seems to have done the trick -- the device shows up and is enumerated perfectly by LibUsbDotNet.  

    In case you (or anyone else) is curious, I'm attaching my patched files.usbdMSdesc.h

    160a161
    >     uint16_t wPropertyNameDummy;    // Dummy property name to be at the end of the list for use by REG_MULTI_SZ
    162a164
    >     uint16_t wPropertyDataDummy;    // Dummy property data to be at the end of the list for use by REG_MULTI_SZ
    164a167,171
    > 
    > // NOTE: Switching this from REG_SZ to REG_MULTI_SZ because LibUsbDotNet is hardcoded to look for DeviceInterfaceGUIDs as part of locating WinUSB devices.
    > //  As such, it won't identify a WinUSB device that sends DeviceInterfaceGUID.
    > //  For more information, see the extended note on this topic here: https://github.com/BrandonLWhite/Stellaris-LaunchPad-UsbDevBulk-AutoWinusbInstall
    > // HACK: To do this, we add a dummy property with null bytes to terminate the list expected by REG_MULTI_SZ
    167,171c174,180
    <     .dwPropertyDataType   = USB_EX_PROPERTY_REG_SZ, \
    <     .wPropertyNameLength  = USB_EX_PROPERTY_NAME_LENGTH_IFGUID, \
    <     .bPropertyName        = L"DeviceInterfaceGUID", \
    <     .dwPropertyDataLength = USB_EX_PROPERTY_DATA_LEN_IFGUID, \
    <     .bPropertyData        = guid \
    ---
    >     .dwPropertyDataType   = USB_EX_PROPERTY_REG_MULTI_SZ, \
    >     .wPropertyNameLength  = USB_EX_PROPERTY_NAME_LENGTH_IFGUID + 0x02, \
    >     .bPropertyName        = L"DeviceInterfaceGUIDs", \
    > 	.wPropertyNameDummy   = 0, \
    >     .dwPropertyDataLength = USB_EX_PROPERTY_DATA_LEN_IFGUID + 0x02, \
    >     .bPropertyData        = guid, \
    > 	.wPropertyDataDummy   = 0 \
    

    Thank you so very much for your work!  I too hope that this can get rolled into the the main TivaWare repository, as not having to deal with signing drivers GREATLY simplifies the development of small USB peripheral projects.  

    Much appreciated!

    --clint