I want to communicate my product string to Windows so that the STM32 device doesn't show as a 'USB Input Device' under the device manager. Is this information derived from the PID/VID, or is there a way for me to communicate a custom product string?
The device itself has various identifications including vendor strings and the VID/PID. You will see these in Device Manager while the device is "unknown" and Windows searches for a driver.
However when Windows matches the VID/PID to a device driver, it uses the strings in the associated driver .ini file rather than those provided by the device.
For a signed driver however, modifying the INI file is not possible with out re-singing it, and Windows will not normally allow unsigned drivers. Moreover recently in Windows 10, drivers must be approved and signed by Microsoft; and you still need your own EV certificate in order to submit your driver for approval. Obtaining your own VID and EV code signing certificate are not free, and testing of drivers for Windows qualification is not straightforward, and service providers to do that for you are expensive too.
Related
What is the additional advantage of developing a full UMDF windows driver if a CDC device is detected as a virtual COM port?.
I have some experience with embedded examples using a microcontroller, both communicating with a terminal like teraterm or using a dedicated USB peripheral that allows for cdc or hid functionality.
Are these drivers the ones you download and install before using any USB device? It is not clear yet what features are avaialble through the host driver.
Often on Windows the "driver" for a USB serial device is no more than an inf file that maps the device VID/PID to the Microsoft usbser.sys CDC/ACM driver.
Recent releases of Windows 10 appear to have stopped insisting that each CDC/ACM have a VID/PID specific inf file, and will load the standard driver for any device that presents as a CDC/ACM device.
The advantage of having a VID/PID specific inf file is that your device can have a vendor specific "friendly name" which can be used in applications to more easily identify your device, rather than just appearing as a generic "USB Serial Device".
One problem with Microsoft's usbser.sys driver (and Linux and Mac OS are no different) until recently was that if you disconnect the USB device, the driver is unloaded even if an application has the COM port open, and the application must close and reopen the port to recover when reconnected. I have previously used a custom driver (provided by a third party), that does not unload if an application has the port open, so that when the USB cable is reconnected, the data connection continues as normal, just as it would if it were an RS-232 cable. However, again in recent versions of Windows 10 I have noticed that usbser.sys appears to exhibit this behaviour in any case.
Note that when you do provide your own driver file, or even just a custom inf file, you will be required to go through WHQL testing in order for your device to be allowed on Windows 10, or to load without warnings on earlier versions. To do that you will need a USB.org assigned VID, an Extended Validation code-signing certificate, and either the tools and facilities to perform the testing, or pay a test house to perform the testing. That all gets somewhat expensive, and may be prohibitive for low volume, low value or non commercial products.
At one time Microsoft too charged for WHQL processing submissions, but no longer do so. That is however little combination since at the same time they changed to requiring an EV certificate and stopped a deal the used to have for low-cost certificate.
The advantage of WHQL qualification is your driver will be provided by Windows Update.
If you are using a USB serial bridge chip rather than your own USB stack and USB controller, then there is a lower cost solution. These chips can be customised with your own VID/PID and descriptors, and the vendor's existing WHQL can be associated to your device so you get all the advantages of your own driver without the costs. Most vendors will even allow you to use their VID and will assign you a unique PID so you can avoid USB.org fees. I have used this route with both Prolific and FTDI devices; it is by far the most cost effective solution.
I need to communicate with some custom hardware that will use either a FTDI or Silicon Labs usb to serial driver.
I found a couple examples but they are older and was hoping for a more up to date example. Plus, I have been confused by the new AppleUSBFTDI kernel driver in how that works with the IOKit and other chips like the Silicon Labs part. It would be nice to have one program that doesn’t care which driver is used.
I have already looked at this example:
FTDI Communication with USB device - Objective C
The nature of these drivers and devices is that they are supposed to function as a standard serial port virtually over USB. So in terms of access it should be no different than accessing a standard RS232 COM port.
I would suggest reading the Serial Programming Guide for POSIX Operating Systems. I'm not sure what older examples you're seeing but serial access itself is many years old, but the idea behind communicating to the serial device is the same in the case of these USB to serial bridge devices.
For information on some Objective-C frameworks, take a look at this Stack Overflow post.
Finally, here is an article directly from the Apple documentation, Working With a Serial Device, and you'll see it also references the POSIX style API.
You should simply need to install the driver associated with your device and plug it in for this to work. In terms of the Silicon Labs CP210x device just download and install the OSX driver. Then plug in your device. This is where the one difference may show up, the name of the tty device on the system (it will show up in the /dev directory). In the case of the CP210x it will show up and be accessible as tty.SLAB_USBtoUART or cu.SLAB_USBtoUART. This will be the name of the device you should open, then use and API from above to start your communication.
My company makes a measurement device that connects to the PC via USB and used to use the Windows in-box USB HID driver. I'm using a different driver now to control the device and I am in the process of signing these drivers for many Windows versions. The reason being we want our customers to be able to install our measurement software (which would pre-install these new drivers), plug in our measurement device, and have Windows trust and use our new driver in favor of the in-box USB HID driver. It would also have the added benefit of using this new driver each time the device is connected no matter what USB port is used or if the user connects a unit that has a different serial number in the descriptor.
I've read through and performed the steps outlined in the KMCS_Walkthrough written by Microsoft to perform Test Signing of this driver by creating a catalog file for Windows 7 x64 from the inf file and signing the catalog file with a self-signed certificate. Things seemed to work smoothly on a Windows 7 x64 machine when rebooted into Test Mode. What surprised me was that I was able to create an XP_x86 catalog file, sign it with my test certificate, import my test certificate into the Trusted Root store and get the driver behavior I wanted on a Windows XP machine. The default driver signing policy was set to the default (Warn - Prompt me each time to choose an action).
I'm surprised because all of the MSDN documentation I have been reading about signing drivers for public release for XP seems to have a strict stance on the drivers being WHQL certified in order for the drivers to be fully trusted as opposed to obtaining a code-signing certificate from a third party and using that to sign the driver. Is this not true? How could my self-signed drivers out-rank the in-box USB HID driver in Windows XP?
I think your experience is normal.
At my company, we have distributed USB drivers to Windows XP users and we never had to sign them to get them installed. We later starting signing them ourselves, but that did not really affect the Windows XP user experience.
Our drivers were usually INF-only or they used WinUSB, so that might be different from you if you are compiling binary drivers.
Without a WHQL signature, Windows XP users can still install your driver package as long at they click through this warning:
After the driver package is installed, in my experience there is nothing that prevents the kernel modules it contains from being loaded into the kernel. However, our users always had to go through the "Found New Hardware Wizard" whenever plugging a new device into their computer for the first time.
Perhaps your driver outranks the HID driver because you picked a more specific identifier string (i.e. one with a vendor ID and product ID in it).
For more information I recommend reading my article: Practical Windows Code and Driver Signing.
After A LOT more trial, error, and research, I've finally come to a conclusion.
The key in my initial question was that I was using a self-signed certificate. I generated the self-signed certificate in Windows using makcert and following the example in the KMCS_Walkthrough:
makecert -r -pe -ss PrivateStore -n CN=CompanyName MyCertificate.cer
The parameter which specifies what Enhanced Key Usages (EKUs) the certificate should be valid for (-eku) is not included. What I didn't know was that with this parameter missing, this creates a self-signed certificate with ALL EKUs. Most notably the EKU called "Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)". This EKU is included in certificates for WHQL signing.
So, in fact, Windows XP was behaving appropriately. My driver was indeed WHQL signed, it was just a self-signed WHQL certificate that was used.
Hi we are a embedded development company (www.emfocus.co.in) and new to driver signing details.currently we are developing a driver for a UPS is just a generic USB HID class device.The device firmware has been written in such a way that the UPS will be enumerated as a Human Interface device
But our intention is to treat our UPS as a HID UPS Battery - a battery class device, instead of a generic HID device. So that when we connect our UPS to the Windows, Windows will detect the UPS as a battery connected to the system and the Windows power manager will communicate to the UPS through HID interface. The HID interface here I mentioned in the driver is not just a generic interface. Its HID Power Device Interface. We defined HID Power Device report descriptor in our mini driver, so that the Windows will enumerate a Top Level Collection which is the HID UPS battery for our UPS. That HID UPS Battery top level collection has been implemented in our mini driver. Actually we can use the Windows InBox driver if we have written the device firmware in such a way that it will enumerate a battery top level collection. But our device firmware is written to enumerate as a generic HID device.
Once the HID UPS Battery has been detected by the Windows, the Windows itself starts sending Feature Report requests for getting Battery Capacity, RunTimeToEmpty, AC Present, Charging status... every thing is working fine.
While those requests are issued to our driver, our driver will communicate to the UPS over USB (with its proprietary protocol) and get the status parameters from the UPS and the driver finishes the IOCTL_HID_GET_FEATURE request with the required values in the feature report and Windows Power Manager displays the status on the Power meter.
So that the UPS battery status will be monitored on the Windows Power Meter itself, since Windows considers our UPS as a HID UPS Battery and not a generic HID device after installing our driver.
We want to have the Windows select our driver inf file at all times while looking for best matching driver files.
So to achieve this we want to know if its ok to sign our driver with our code signing certificate or to get the driver WHQL certified ?
If you are just looking to get your device "installable" on an end users system without warnings or signing errors you can create catalog files for the INF installation and sign them with your code signing certificate. The downside to this is that you have to distribute and install the certificate to your users' machines as a trusted publisher before trying to install the device through it's INF.
Alternatively running through the WHQL HCK tests will require that you acquire test logs (for each OS) and submit them to Microsoft for a fee to review and provide a WHQL signature on CAT files created through the HCK submission process. This route is the cleanest for the user because it requires no certificate distribution and also proves that your device passes the WHQL HCK tests.
So the answer depends on what you are trying to do and who your target audience is. I would opt for the WHQL route if you can afford it, as it provides the most benefit for the end users.
Description of the problem:
Insert USB-HID Device (Barcode scanner) on a clean Windows XP Machine.
After windows loads the USB-HID Driver.
Windows XP pops a dialog box asking the user to reboot the machine. (This is the problem)
Scenario:
Remotely Deploy a software package to talk to these devices. (no hardware at this point)
Remotely reboot machines.
Hardware is added to each machine. (no reboot)
Investigation:
Windows adds a control class referencing the "usb.inf" file.
Windows adds a device class referencing the control class.
Windows adds a enumerates the device referencing the device and HIDClass.
I believe what needs to be done is to "Pre-load" or "Pre-install" the driver, but we do not provide the INF files (provided via usb.inf).
Our other drivers utilize dpinst to handle installation on a different driver interface (btw this procedure does work for the desired behavior), but we are providing those INF / CAT / SYS files.
Is it possible to leverage SetupCopyOEMInf to perform this function?
What other avenues could be pursued to pre-load/pre-install this driver?
As it turns out, the problem was connecting to a device before it had enumerated its sub devices, locking the device tree, which caused the 'please reboot windows' dialog to appear when the last device enumerated.