USB not indicating correct number of string descriptors

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

Hello All,

Just registered to this forum. I've been using CCS for some time on various projects and so far I've been able to solve problems just by searching this forum. Now I've encountered a problem that seems not to be reported earlier.

Yesterday I was trying to find out a solution to a known problem (with no luck). If you have a composite USB HID device with 2 joysticks, Windows only uses name of first device for both devices. This has been discussed here before and is likely to be a Windows problem.

I came across a tool called SimpleHidWrite http://janaxelson.com/hidpage.htm#tools, which allows some debugging with Hid devices. This tool recognizes both devices with correct names from the composite USB device. There is also an info button, which allows to see more information from the selected HID device. It shows VID/PID, serial number, report sizes and all strings from the device. All the strings are shown as they should, but after them there are garbage strings, up to 255. It seems as the number of strings reported by the device is not correct, and when requesting strings that do not exist, incorrect data is sent by the PIC.

In the examples, there is line

Ttelmah · Joined: 11 Mar 2010 Posts: 19499

That line is a 'left over' from the older USB driver. Not used in the current driver.
The descriptor count, doesn't change with multiple devices. Look at the KB/mouse example.

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

The string descriptor count can vary. The CCS examples have only 3 strings (language, manufacturer, product). My composite device has 6 strings; serial number and separate names for both interfaces in addition to the before mentioned 3. All 6 strings show up us they should, but after them begin the garbage strings on SimpleHidWrite.

On comparison, I tested some other devices, a PS2 gamepad adapter (implemented with a Cypress µC) and a barcode reader. They both show manufacturer and product strings correctly, and no garbage after those. But then I tested Pickit2 and Pickit3, they also show garbage so the same 'feauture' seems to be in Microchip USB stack also. But then again I saw a screenshot from SimpleHidWrite on Microchip forum and there was no garbage. Strange..

Ttelmah · Joined: 11 Mar 2010 Posts: 19499

Yes, the number of string descriptors can vary, but it doesn't directly have any relation to the number of devices. You can have exactly the same number of descriptors with one device, or five (if you want). You specify which string is to be used for the device, in the interface descriptor index.

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

Ok, maybe I formulated the topic badly. The only thing I'm wondering is if I can get rid of those garbage strings.

I just guessed that it those are shown because PIC doesn't report the number of strings available. Or it just replies to queries of strings that do not exist.

Ttelmah · Joined: 11 Mar 2010 Posts: 19499

It actually sounds to me as if the code you are using is trying to read beyond the number of devices being implemented, or one of the descriptor indexes contains a number beyond the end of the actual array (or an index exists beyond the number of entries).

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

But the same code doesn't get garbage strings from some other USB devices I tested. So I think it could be fixed in PIC FW. But it might not be worth the effort and/or increased code size..

Ttelmah · Joined: 11 Mar 2010 Posts: 19499

Which is why I said:
"or one of the descriptor indexes contains a number beyond the end of the actual array (or an index exists beyond the number of entries)."
This would be down to the entries in your tables.

gpsmikey · Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA

I wonder if what you have run into is related to the issue I ran into some time ago with the PICKIT2 - it would crash / prevent startup of my video editor and even caused the dxdiag utility to fail. Unplugging the PicKit2 from the usb port fixed the problem. See my original post www.ccsinfo.com/forum/viewtopic.php?t=44471

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

rksjbeck · Joined: 10 Sep 2009 Posts: 3 Location: Atlanta, GA

Yes, the CCS implementation will respond to any string descriptor request, even if it is an offset that doesn't have any data there. As someone pointed out, there was a time when the stack used the size of the offset array, but now it doesn't.
If you are still having this problem, let me know.
There is a pretty simple patch to the USB stack that fixes the problem.

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

I am still having this 'problem'. I did try to look the USB stack code to fix the behavior, but couldn't figure out how to do it in reasonable time.

I would like to try out the patch, would be very nice to get this sorted out.

rksjbeck · Joined: 10 Sep 2009 Posts: 3 Location: Atlanta, GA

In the module usb.c go to the "void usb_Get_Descriptor() " function and under the "case USB_DESC_STRING_TYPE: //3" change that entire case statement to :

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

The patch works like a charm! Thanks rksjbeck, you're the man!

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

Even with the patch applied, Hid Device Exerciser tool shows that the device has 255 strings. Some other commercial devices show the value correctly.

The tool is available here: http://janaxelson.com/files/HidTest.zip

I did some experimenting and changed this line from patch

jaka · Joined: 04 May 2014 Posts: 35 Location: Finland

I recently renewed my CCS maintenance and found that the garbage string problem has been fixed on Feb 6, 2015. (from usb.c file) Quite soon after the solution was posted here!

Hid Device Exerciser still shows that device has 255 strings, but that's not too much of annoyance.