Thursday, September 23, 2021

USB HID Fun for Windows

Almost all the electronics I build rely on a USB HID connection.  USB HID is built into all major operating systems and makes device connection much simpler.  The downside is small transfer size, but my designs rarely move large amounts of data.  While I could probably write an OS driver for other USB implementations, that is time I would rather dedicated to new ideas.  On the Windows side I use RAD Studio (Delphi) to build the Windows Apps.  ( I also use this for the Android Apps).  For the USB HID component I have been using the JEDI project VCL controls, which include a USB HID non-visual control.  Once I determined the correct configuration, this has performed quite well.  It did take a few months to "wring out" all the nuances of the control.

Several months ago I started noticing issues when connecting to the device.  Then apps with USB HID interfaces would not compile. This all began with a new version of the compiler (10.4.x).  I backed up to the previous version and all was great, kind of.  There were still issues on occasion.  (In retrospect, it was only one computer, my HP Elitebook 850 G5, giving me issues on previously compiled apps.)

After too many days of researching this USB issue, I finally found it.  The USB HID component is part of the JEDI VCL library, provided as source.   The source is kept up to date through the JEDI group and has an extensive "ifdef" structure, to ensure backwards compatibility for many versions of RAD Studio.  The USB HID component is compiled when it is installed into the RAD Studio IDE  component palette, this way it is compatible with multiple versions of the compiler.  Sometime after version 10.4.2 of the compiler was released, several patches were released.  Long story short, when the USB HID was installed (without patches), the compilation corrupted the registry access when enumerating the installed HID devices. When I installed the latest version of the compiler on a clean PC, updated all the patches and then installed the USB HID component, it worked just fine, kind of....................

It worked on all the computers, except my HP Elitebook 850 G5 laptop, that is my primary computer.  I kept putting off working on it because it looked like some kind of driver/registry corruption and reinstalling windows and then all the software looked like the only solution.  Well that was not something I wanted to do.  But today it got to be too much, so before trying to reinstall Windows and rebuild the entire computer, I started debugging again. 

What I noticed is that sometimes it would enumerate some HID devices before failing and other times it failed immediately.  So then I started tracking Vendor ID/Product ID data on each device.  After several runs a trend started to appear, it was always the same device failing, but at different points in the enumeration.  Something called "HID Sensor Collection V2".  I disabled the device and then all of the USB HID programs started working.  Looking at my other two computers, neither has this device.  Further digging showed that Windows would allow the generic HID compatible driver to be attached to the device and that also worked.

I have a USB HID exerciser that Microchip use to provide for PIC USB HID development.  It is a small Windows program that gives you all the data on your device in order to verify operation.  It never shows this HID device, unless I use the generic HID driver.  What is happening is that a call to the Windows HID.dll is returning a failure(HidD_GetAttributes), which is verified by the error message the HID exerciser is showing.  Looking into the open source code I am using for the HID interface and tracing to the failure, it is the same call to the HID.dll.  So now I am pretty sure I have found the problem.

So what does this device do?  Dont know for sure, but it looks like it controls several accessories like accelrometer, gyro, temp etc.  The list of devices implies it is for a tablet or tablet mode of a PC.  For now I will use the generic driver and see if anything fails.  The error checking at that point in the code is not robust enough to handle that error and let the program continue to run. On the JEDI forum this problem had been previously noted and I added my data.  A proposed solution is to  ignore the error.  Workable, but not elegant.  Once I get a few more things done, I plan to return to this and see if I cant come up with a solution that will work for more people.

 




No comments:

Post a Comment