PORTS Forum
Ports and Interfaces => USB => Topic started by: jdunne on April 26, 2011, 12:17:57 pm
-
Hello,
I'm attempting to make my USB device compliant with the USBCV tool. It works perfectly fine under normal use, but when I attempt to test the device it fails the HID Tests. The error is quite cryptic and very unhelpful. I'm hoping somebody has knows of a tool that can be used to verify report descriptors.
Following is the error, which is about as helpful as it saying "Error.":
Now Starting Test: HID Class Report Descriptor Test (Configuration Index 0)
Start time: Tue Apr 26 10:55:24 2011
External report descriptor parser 0x200 warnings
External report descriptor parser 0xA errors
(3.2.61) The report descriptor returned in response to a GetDescriptor(Report)
must be compliant with the HID specification.
I looked into Windows kernel debugging, but got scared and ran for the hills. Ideally I'd like to just generate a .log file of the enumeration process without having to use all the crazy 2 PC setups they have. Has anyone used Windows kernel debugging to debug an HID device? I'd be more willing to put in the effort if I knew I'd get a useful output. Like I said, the device works, so I'm not really sure if Windows would even show an error in the debug trace. If anything it might be a warning.
Anyway, does anyone know of a tool to check for errors in HID report descriptors? Mine are quite lengthy and I can't post them here, so I'm really looking for suggestions of tools to use.
I might be crazy, but I recall using an application several years ago which output an HTML page showing report descriptor errors. I can't remember what its called and I can't seem to find it in any of my tools. The only thing I remember is that I'm fairly certain it was either a Perl script or a Python script.
Joe
-
The HID descriptor tool is here:
http://www.usb.org/developers/hidpage#HID%20Descriptor%20Tool
Jan
-
Jan,
Thanks for the reply. The HID descriptor tool is useful for creating a report descriptor. It is not useful for verifying one is correct. I'm trying to determine why usbcv is telling me that it doesn't like my descriptors.
Joe
-
That's the only tool I can recall. You could try removing sections of the descriptor and retesting to try to isolate the problem.
If the device enumerates, I don't think debugging the enumeration will show anything.
Jan
-
Jan,
That's the same conclusion I came to. I have another similar device which does pass the usbcv test and I'm presently in the process of copying portions of the working descriptor over until I get a pass result. Thanks for the input.
Joe
-
Jan,
You were right! HID Descriptor tool that you linked to contains a parser. I never realized it before. The main reason I hadn't noticed the parser is because I never use the tool because its such a piece of junk to actually use to manually create report descriptors.
Anyway, having discovered that it contains a parser I wanted to import my ridiculously large report descriptor (1200 bytes) into DT's proprietary .HID format. I wrote up a quick and dirty parser this morning that parses a .c source descriptor and converts it to the .HID format. This allows a pre-existing report descriptor to be imported into the descriptor tool for debugging.
I'd like to post the source and application, but it appears your site doesn't allow attachments. Any suggestions where or how to post it? Otherwise I guess I'll post it on Microchip's forum and link to that. I'd like to share my tool so others can benefit from it.
Joe
-
I've re-enabled attachments.
Jan
-
From the readme.txt
HID Descriptor tool import tool
The version 2.4 HID descriptor tool from usb.org tragically doesn't contain an import .c file functionality.
It only supports its own proprietary .hid file format (which fortunately is fairly simple).
This tool is written in VB6.
This tool imports a .c file containing only the report descriptor and outputs a .hid file containing the descriptors
imported. Note that DT.exe will choke when trying to parse the descriptor unless actually COPY the .HID file to the
folder where the dt.exe tool is located.
Limitations of the tool: (I threw this together in 2 hours, so don't expect perfection)
1. The tool properly ignores // comment lines and BLANK lines, but does not support C style comments /* */ Remove C style comments if they are used in your application.
2. The tool looks for a comma to determine if the line contains data. (It isn't exactly all that intelligent of a parser) This usually means you'll have to add a comma to the LAST line of your descriptor definition for the tool to find it properly. (See the example)
3. The tool only supports ONE ITEM PER LINE!! So, if you've got 0xC0, 0xC0 on a single line to end 2 collections, the tool will FAIL to import that line.
Enjoy.
Joe
[attachment deleted by admin]
-
Hello,
Having used my newly created tool to import my report descriptors into the HID report descriptor tool from usb.org, I've now solved my problems, which turned out that I had my logical minimum defined larger than my logical maximum for a few report items.
Also, the cryptic error message from USB20CV:
External report descriptor parser 0x200 warnings
External report descriptor parser 0xA errors
(3.2.61) The report descriptor returned in response to a GetDescriptor(Report)
must be compliant with the HID specification.
As it turns out, the line that reads "External report descriptor parser 0xA errors" actually means there are 0x0A == 10 (TEN) errors in my report descriptor. The hex formatting threw me off. I guess that they have another formatting issue because the 0x200 warnings actually means there are 2 (TWO) warnings.
Hopefully this information helps somebody down the road. I have wasted a day of my life on this mess.
Joe
-
By the way, the .hid file output from my tool needs to be copied to the same folder as the dt.exe file otherwise dt.exe throws a bunch of errors when trying to load it.
Joe
-
Glad you found the problem.
Jan
-
HID descriptor tool on USB.org applies the same parser DLL (Tparse.dll) as USB20CV, supplied by Intel. But the version of the engine on HID descriptor tool is not updated so long, though those of USB20CV are often updated.
To update HID descriptor tool using USB20CV files, drag in these files from USB20CV and replace them all.
C:\Program Files\USB-IF Test Suite\USB20CV\lib\
- Tparse.dll
- dt.ini
- *.upg
And then, you'll get the same parser result on HID descriptor tool as USB20CV, also with more user-friendly error message.
Tsuneo
-
Tsuneo,
Thank you! I will definitely update my descriptor tool to use the latest parser. Its too bad they didn't include source for the tool because its quite buggy. Hopefully the updated files will help.
Joe
-
Thanks, Tsuneo!
Jan
-
Folks,
I am struggling with some Spectrum Digital USB code for a TI C55xx DSP (as apparently *many* people do) and would appreciate some guidance. The sample source code for the report descriptor appears to be poorly formatted:
Uint8 reportDesc[] = {0x05,0x01,0x09,0x02,0xa1,0x01,0x09,0x01,
0xa1,0x00,0x05,0x09,0x19,0x01,0x29,0x03,
0x15,0x00,0x25,0x01,0x95,0x03,0x75,0x01,
0x81,0x02,0x95,0x01,0x75,0x05,0x81,0x01,
0x05,0x01,0x09,0x30,0x09,0x31,0x09,0x38,
0x15,0x81,0x25,0x7f,0x75,0x08,0x95,0x03,
0x81,0x06,0xc0,0xc0};I would like to use jdunne's DTImport tool, but since it requires that each line only contain the appropriate number of bytes, will not parse properly. Can someone help me figure out the proper formatting for this descriptor?
Guidance appreciated.
Thx,
MikeH
-
(I see that DTImporter is posted earlier in this thread.) Offhand I don't know for sure, but perhaps it wants each item in a separate line? If so, you would need to decode the values in the descriptor and reformat it. For example, line 1 would be
0x05 0x01 (Usage page Generic Desktop)
Jan
-
Jan, you are correct, but I think MikeH already noticed that and was looking for help decoding his report descriptors into a format like that. The simplest way I can think of to do that is to use a USB bus analyzer (I use CATC USB Chief) which will decode the report descriptor for you.
If you don't have a USB bus analyzer, the other way is to get the HID specification and manually decode the data. Your descriptor isn't that long, so it should only take a couple hours or so to decode at worst case.
There might be a software tool which will do the job, but I've never heard of it. I did quite a bit of searching too a while back.
Good Luck.
Joe
-
Joe,
You are correct. I was just looking for help decoding this mess....:) I agree that a bus analyzer is the best/easiest way. I think I'm going to spring for one of the ~$200 software analyzers. Thanks for your help and your importer.
MikeH
-
Just for completeness, here's the results of the decoded, poorly formatted HID reports descriptor (using USBlyzer):
Interface 0 HID Report Descriptor Mouse
Item Tag (Value) Raw Data
Usage Page (Generic Desktop) 05 01
Usage (Mouse) 09 02
Collection (Application) A1 01
Usage (Pointer) 09 01
Collection (Physical) A1 00
Usage Page (Button) 05 09
Usage Minimum (Button 1) 19 01
Usage Maximum (Button 3) 29 03
Logical Minimum (0) 15 00
Logical Maximum (1) 25 01
Report Count (3) 95 03
Report Size (1) 75 01
Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit) 81 02
Report Count (1) 95 01
Report Size (5) 75 05
Input (Cnst,Ary,Abs) 81 01
Usage Page (Generic Desktop) 05 01
Usage (X) 09 30
Usage (Y) 09 31
Usage (Wheel) 09 38
Logical Minimum (-127) 15 81
Logical Maximum (127) 25 7F
Report Size (8) 75 08
Report Count (3) 95 03
Input (Data,Var,Rel,NWrp,Lin,Pref,NNul,Bit) 81 06
End Collection C0
End Collection C0
Thanks for the suggestion.
-
MikeH,
Glad you got it sorted out. Now you can run it through DTImporter and make sure there are no errors.
Joe
-
It looks like my attachment of DTImporter from long ago is now gone. I've moved the tool to github:
Summary of the tool:
The version 2.4 HID descriptor tool from usb.org tragically doesn't contain an import .c file functionality. It only supports its own proprietary .hid file format (which fortunately is fairly simple). This tool is written in VB6.
https://github.com/jdunne525/DTImporter
-
Thanks for letting us know!