USB not indicating correct number of string descriptors

[jaka]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[jaka]

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]

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.