USBDevice in-box WinUSB Driver Installation

NETMF & Gadgeteer
1

A major client is planning to roll out Windows 10 next year, and in compatibility testing our existing USBDevice/WinUSB devices we found Win10’s requirement for signed drivers to be a problem.

Having the in-box drivers load automatically seemed to be the way to go, and I spent some time getting the descriptors right (easy in C, not so easy in C# where everything is hidden away under the hood), but eventually I had the special string descriptor, WCID descriptor and an extended property descriptor working on our EMX based hardware in test programs on 4.2 (GHI.Premium.USBClient) and 4.3 firmware.

The xusb test program (on a Linux test box to avoid polluting the Windows registry) showed my device was returning everything needed to automatically install the driver when the device was plugged in, the same as other commercial devices did.

However when I tried it on test Win10 systems, it wasn’t recognized, and it took a bit more searching to to find that GHI had basically hard-coded the USB version 1.1 (bcdUSB = 0x0110) in, while Windows required USB >= 2.0 (bcdUSB = 0x0200) for it to query these descriptors.

After much mucking around trying to find a way to override/extend this value (I really do prefer C to C#!) I came here to ask the forum for help. And then I found the question had been asked before, added to the task tracker, and then closed with no reason given.

It seems more than a VERY nice to have feature, almost essential these days, so why was it closed without any reason at all being given?

The previous comment thread on this is at:
Custom USB device with WinUSB and no INF file required to install

This is the closed Task Tracker Entry

2

The firmware was designed many years ago, before windows 10. However, commercial users get the best experience by working with us directly. So give us a call or send an email with details on your project. As a partner, we will make sure you can fulfill all your customer’s needs.

1 Like
3

@C_Born I created and was involved in the effort to get WinUSB task tracker issue working in the last Release Version 4.3, I kind of assumed it was known that WinUSB driver had replaced the previous (yet still available) GHIElectronics USB drivers, since it was mentioned as a feature in the release notes. Hence the Initial issue was closed by GHI Electronics. I wanted to piggy back some other issues on to this task as well.

The EMX LPC2478 hardware only supports the “full speed” section of the USB 2.0 specification. Hence I believe the current version as 1.1 in the descriptor is working, these values were used in other implementations. While this may not meet the Microsoft requirements as mentioned on page 5 of the Microsoft OS_Desc_Intro.doc. The USB specification may take precedence here.

Have you tried a different USB ProductID?
This would be required if you tried that ProductID with a bad descriptor.

I don’t have and EMX module to test with but we use the G80, G120 and G400 with the WinUSB driver very successfully.

Run the USBView program and if you post it’s output back to the forum, I maybe able to help you further.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/usbview

Hope this helps,

Phil

2 Likes
4

@PHITEK Thanks for your reply Phil, hopefully with help from you and @Gus_Issa I’ll be able to get this working.

We have actually been using the WinUSB drivers with these devices from the start, but we have been installing on Windows 7 with a custom .INF. I hadn’t looked into completely hands-free WCID based installation before, although apparently with the right USB descriptors on the device it has been working since Windows 8 right out of the box, and automatically with Windows 7 with a one-off download of the WinUSB drivers from Microsoft (That wouldn’t have worked for our client as the process machines are not allowed internet access)

Anyway now we have been given a corporate “standard build” VM image to test on, these things are so locked down by Group Policy almost everything is going to fail somehow, and the first hurdle was the requirement for signed drivers. The WinUSB drivers themselves are signed, but the custom .INF means they won’t be loaded, at least not without some trickery that I’d rather not require of the end users.

The best source of information I’ve come across on setting the device up so drivers auto-install can be found here: https://github.com/pbatard/libwdi/wiki/WCID-Devices

(The required descriptors actually appear in various forms in the USB config files in the GHI NETMF-Open-Firmware Git repo right from the start, in easy to read C.)

I worked through the process of building them in C# until they all appeared correct, using the the xusb tool from the examples in libusb (https://github.com/libusb/libusb.git) under Linux, to avoid the problem of polluting the Windows registry with bad versions. (Testing on Windows I updated the Product number for each build, and reverted to a saved VM snapshot every so often for a clean start)

[BTW xusb is a great tool, clearly coded and easy to modify. One minor fault in the current version is that it converts the Unicode string descriptors to Ascii to display them, which means the Vendor code at the end of the MSFT001 string may not be displayed correctly, but that is easy to fix and there is a pull-request waiting to do just that.]

I’m not sure what will happen when/if I manage to change to bcdUSB code to 0x0200, I was hoping it would be easy to do and everything would fall into place, but of course it may bring other problems that bring the USB stack down, Gus probably knows that better than anyone.

Not being an expert in C#, I thought for a start I could derive from the GHI USBClient to change the code, but as it uses a static class that didn’t work. Then I tried extension methods, still no go. Then tried building the whole class from scratch using the JetBrains decompiled code and calls into the DLL, but that didn’t seem to work properly either.
My thoughts were then “All I want to do is change one byte, it shouldn’t be so hard, I don’t know why anyone would use C# when C is so much better in every way, and why do they have to keep coming up with new languages every few months?”, showing my age and ingrained bias from 35 years coding in C, and turned to this forum :slight_smile:

I’ll take another look at it tomorrow (and post anything useful I get from USBView), but if someone can see an obvious thing I’m missing (likely), or knows it can’t be done at all with the 4.2 firmware I’m using (also likely), please let me know!

5

@C_Born That is a good link you provided on WIDC, also there is a reference to NETMON which I did not know about, to capture the USB enumeration sequence.

I doubt you will get the 4.2 firmware to work, that is what I tested against and provide USB Anaylzer traces back to GHI Electronics with. This then allowed GHI Electronics to move to the WinUSB driver.

Also just make sure to try a different ProductID to eliminate the chance of a bad set of descriptors from an earlier USB enumeration attempt.

Phil

6

@PHITEK I added the required descriptors from my test program (NETMF 4.3) back into our 4.2 production image, and it sends the descriptors out on request as you can see in the xusb output.

image.png736×522 29.7 KB

image.png810×856 20.7 KB

Although it doesn’t automatically install the WinUSB drivers, as you can see in the USBView display bcdUSB is only 0x110, I did hope that if I manually installed the WinUSB driver it might manage to pick up the DeviceInterfaceGuid, but checking the registry this doesn’t happen, and so there is no way for the service (PC end of the connection) to detect the device is connected.

I know the standard CDC/serial, HID and Mass Storage drivers install automatically, but have you had success with the generic WinUSB auto-install with any of the other platforms you are using? I can try on a G120 if that makes a difference, at least as far as confirming I’m on the right track!

@Gus_Issa - The product is our standard anode meter. We are currently doing Windows 10 compatibility tests for a rollout next year with a local plant, but we have a lot of these in plants in Canada, a few in the US and Brazil, and I want to make the transition as smooth as possible for everyone.
I’ve just done testing for some of our larger systems (in-house hardware and software coded in C, installed around 25 years ago) and the only mods required took around 1/10 of the time I’ve spent on these 3 year old systems so far. It was all meant to be so easy! :smiley:

7

@C_Born I only had a successful auto-install with the Released NETMF v4.3 SDK and firmware.

For the windows software side we used Jan Axelson as a starting point.
Jan Axelson's Lakeview Research

I should have some time this evening to bring up my USB analyzer trace logs, and review my project documentation, all of which was provide to GHI Electronics. Also will look over your screen shots in more detail later as well.

If you must have a solution based on the Version 4.2 SDK, you will likely need GHI Electronics to do a “private” or possibly to the community release based on their changes to the Version 4.3 code base.

Phil

P.S. Cool products by the way!

8

@C_Born - I checked my notes and you are getting further then I was able to. My issues where also with bcdVersion, but in the end I left it set to 1.1. The main issue was when DeviceInterfaceGUID was requested with index=5 the USB Analyzer would get a “Setup txn” packet which failed the USB transfer. You seem to be getting the DeviceInterfaceGUID response. I had a quick look at the HEX dump and noticed two things, in your descriptor you have “Guid” and I am using “GUID” not sure if this would cause a problem(I might try this if I get a chance tonight) and there seems to be a “N” after Guid and before the “{” which I do not have in my descriptor.

Phil

9

@C_Born - Then “N” I referenced in the previous post, is a byte count for the DeviceInterfaceGUID, so the “N” is a byte count of 0x4e but I am using 0x40, plus I think you are missing three 0x00 bytes following the USB_CPROPERTY_DATA_LENGTH of 0x40.

Anyway reviewing this section of the descriptor should help.

Phil

10

@C_Born - I should have mentioned that we had initially tried the GHIElectronics USBClient but switched to the Microsoft WinUSB client to have the ability to override the descriptors. We did try setting the bcdVersion to 1.1 but left it at its default value 2.0. In checking the bcdVersion value as observed with USBView it is in fact 2.0.

using Microsoft.SPOT.Hardware.UsbClient;

So sorry for the bad information on bcdVersion.

I now have the gained the support of a colleague at work, so we are both trying to support you now.

Phil

11

@PHITEK Thanks for all that info Phil, I’ll follow up on that link, which looks like it has some good information, and check through my descriptors again in detail.

I’ll also have another go at using the Microsoft UsbClient stuff directly, I did try that at the start but didn’t get it working, and was then unsure whether GHI was fully supporting it at the lower levels. The source level debugging with NETMF and Visual Studio is great, but I hate it when things disappear into native code and you lose sight of what is going on, I really want to track everything down to the assembly code!
GHI’s USBClient makes things very easy to get going, and I use it to quickly switch between Raw USB mode and Mass Storage on our device, but it does come with some loss of flexibility.

I’m not welded on to 4.2, and I have a working 4.3 branch, but the problem comes with installed user base. There are sites that bought a lot of these meters, then my technical contact disappeared, so I really don’t want to have to try and train operators in how to upgrade the the firmware at that level, and I also would rather avoid having build and distribute multiple versions of our software, again having the user figure out if they are on 4.2 or 4.3 isn’t easy.

I’ll be interested to see how TinyCLR works out, but much more so if it was fully open source.

David

12

I’m of a similar mindset although two things seem to be of concern.

#1 GHI puts in an enormous time and effort in to reviving a framework that the community failed to carry on (well, that and one guy who was in charge of NETMF repository not committing any changes for ages…)

#2 GHI has to make money somehow.

We can all understand #1, and appreciate #2, because commercial users of this understand that the whole point of designing new stuff is to … well, pay the bills. Feed the kids. Make a few bucks.

I’m just staring on this venture in to embedded stuff. I’m holding good faith that GHI is going to back me up if and when I hit a roadblock that is buried in closed source.

I mean, it’s in their best interest to do so. So I have to assume that they will, until some time that faith is disproven, it’s there.

If they don’t support the community they are working to build/continue building/ rebuild after the abandonment of MS, then they aren’t viable.

And one thing I’ve learned about business over the last 2 decades of owning a software development firm, is that survival is the #1 concern.

So I believe they will take care of us.

…And externalize stuff that we need externalized while protecting their IP in the time, energy, and “leap of faith” they have taken in carrying NETMF to the “next level”

For me, I’m designing everything exclusively in NETMF until TinyCLR OS become mature and out of pre-release, and probably until it’s out of alpha and beta. Once it’s solid I’ll migrate the framework I’m building over to it.

I’m looking forward to it, and where GHI is going.

Perhaps in some future turn, the interpreter OS will become open source. Between now and then, I think they’ve shown that they have been responsive to suggestions, and willing to make it work for us.

Anyway that’s my .02 on closed source. It’s fine by me as long as the company takes care of us.

And if they don’t I’ll reverse engineer the heck out of it.

:slight_smile:

13

@trent1098s I quite agree, I think Gus and his crew have done an amazing job in building and supporting these devices over the years, he puts so much time and energy into it and still manages to answer questions from people like us personally, it is something he should be very proud of.
Finding a business model that allows him to employ people. provide a product, and actually make some money is important, we do want to see them keep going.
When all the income comes from selling hardware (or hardware loaded with firmware) and not from actually selling software, I don’t know that making the software all open source would be a disadvantage or a big plus for them though?

With all the open source Linux and Android distros around now, it is a tough market to be in, and it looks like Microsoft saw the writing on the wall. I just hope Gus can continue to forge ahead in this niche market-space.

14

The trick is to make it “not niche.”

There’s huge money in automation and control systems and the big players (Siemens, Honeywell, Johnson, Panasonic, etc) have billions in proprietary, closed source systems with dedicated marketing, distribution, and support channels. Meanwhile, Internet of Things is evolving and technology like we’re messing around with continues to evolve and mature - sooner or later, those big players will lose more of that iron clad grip they have on the markets.

GHI pursuing the educational aspects, strongly, is absolutely the correct “long play.”

I would think that if open source is not an option (they want to protect their investment, right?) then perhaps at some juncture a licensed partner open source program would be the right move? A lot of companies have done that in the past, sign an NDA and get source.

Other companies (Telerik, etc) offer source with their license subscriptions, as well, so it’s becoming more common these days.

I will say one thing. It’s rather amazing GHI can do what they do. I’m not sure what the margin is on the various platforms, but when I see them supplying the level of support they do to a guy with a one-off Gxx, that they maybe made a couple bucks off of, it’s impressive. Plus the teaching and educational channels (tech talk, brain pads, etc).

However hardware sales are tough to budget on - even with commercial users bringing in more volume, relying on sales alone is tough for any company because sales rise and fall, come and go. A recurring income, monthly or annually or whatever, makes it much easier to plan projects. I can’t help but wonder what the timeline or feature set on TinyCLR OS would be with more resources, and if those resources could be obtained by a subscription / support model (which may include, perhaps, open source on the platform under NDA).

Then again… I’m just talking here. Not my business to run. . :slight_smile:

15

Thank you guys. I am reading your discussion and I feel inspired to do even more.

By the way, NETMF is open source and it failed. I am not seeing the community doing much there, sadly. Not every open source project succeeds. We are now more focused on the quality of TinyCLR. How do we make money,? This is a later concern.

2 Likes
16

We are pursuing all aspects. You still haven’t seen the big things we are working on. BrainPad, FEZ, TinyCLR are just a fraction of what to come by the end of this year. We are a lean and mean team that can do amazing things in a relatively short time.

2 Likes
17

@PHITEK @Gus_Issa
Phil, after you said it was working only with the Microsoft UsbClient I went back to the original codeshare project I had spent a lot of time trying to get to work, the same one I later found you had tried and given up on, https://www.ghielectronics.com/community/forum/topic?id=14732&page=2
but I still didn’t get anywhere with it.

I then decided to go back to the original source and build the Mouse sample provided by Microsoft right from the start, and updated to use use USB 2.0 at version 4.3 in the GHI repo. I tried both the original and the updated one, with firmware 4.2 and 4.3 installed, but no go. When I trace it (I’m debugging over the serial port) it gets to

        // Kick the USB controller into action.
        if (!port.Start())

with the configuration accepted (ConfigOK) but Start() (which calls nativeStart()) returns false, with no indication of why it failed.
NETMF-Open-Firmware/Product/Samples/USBDevice/Mouse at master · ghi-electronics/NETMF-Open-Firmware · GitHub
https://github.com/ghi-electronics/NETMF-Open-Firmware/tree/master/Product/Samples/USBDevice/Mouse
I figure that as it was updated at release 4.3, it should have been tested and working at that release?

Can anyone replicate/verify this result? I don’t think it is my hardware, as the USB is working properly when using the GHI USBDevice code, running 4.2 or 4.3. The sample is very easy to set up, although you probably need to comment out the Button setups. I also tried forcing a reconfig, despite one being read in from the controller, but that didn’t help with the failed Start().

18

@C_Born - I maybe wasn’t quite clear by what I meant by “working”. Your setup that produced the hex dump of the DeviceInterfaceGUID shows you got a response to GetDescriptors index=5, my GetDescriptors index=5 did not get a response until the final release of Version 4.3 SDK and firmware.

However your DeviceInterfaceGUID has three differences when compared to my “working” request for index=5, check previous post for details.

I have one more issue I want to check my notes for that may be useful for your environment.

Phil

19

@PHITEK - If you have any working example using the Microsoft UsbClient (Microsoft.SPOT.Hardware.UsbClient) rather than the GHI one I would love to see/try it, the only examples I have are the original Mouse one provided with the SDKs (see above), and the one you tried from Codeshare, and for me they both fail to start the UsbController, the Start() call just returns false despite configuration passing. I’m assuming GHI changed something required in the setup, but I haven’t found it documented anywhere. At least if I have a minimal case where I can Start() the controller I can build from that.

Using the GHI.Premium.UsbCient I can get the required descriptors returned using the xusb test program, the problem is that Windows won’t even query for those descriptors unless the device identifies as USB 2.0, and the GHI.Premium.UsbCient overrides any attempt to set that for the raw device, hence the need to get a test program working with the underlying Microsoft UsbClient.

20

@C_Born - I just confirmed that the previous releases to Version 4.3 SDK and firmware that a race condition existed on the G80 platform. Can’t say that this would apply to the EMX platform. GHI Electronics recommended to wait for a button press before initializing the USB Controller.

Good point about releasing a working USBClient, That was my plan initially but there was “no” interest from the community at the time so that did not happen.

Since then that base project has been cleanup and some of my company’s project code base has been added. I would also like to release it with a Windows user mode program to demonstrate the basic use case.

I will have to take this request under further consideration for now.

Phil