Reading a dev s/no and manufacturer with HID commands.

[rallysjd]

My ARM M3 boards have a chip unique 96 bit serial number. My HID firmware gets this number and writes into the CustomHID_StringSerial[CUSTOMHID_SIZ_STRING_SERIAL] array. The s/no is converted into 24 hex characters in the firmware.

Now here's the problem. When I call HidD_GetSerialNumberString, I get the first 14 characters only. Similarly, if I call HidD_GetManufacturerString I get the first 18 characters only. According to the HID SDK help, both these strings can be up to 126 wide chars. I'm passing in a wide char buffer that can handle this maximum.

I don't see anything in my CustomHID_StringVendor or CustomHID_StringSerial or CustomHID_ConfigDescriptor that set the size limits of 14 and 18.

Uninstall/reinstall the drivers from Device Manager makes no difference.

Is there a size setting I've missed in the firmware or might the issue be in the HidD_Get* commands?

SD

[Jan Axelson]

Are you storing the strings as 16-bit Unicode characters with the correct value in wLength of the Setup packet?

Jan

[rallysjd]

Yes, all the strings are unicode. My buffer is 126 WCHARs.  If I reduce the value of length arg of the buffer in HidD_GetSerialNumberString to less than 32, it returns 0 and a null string as expected. 32 or above gives the first 14 characters of the serial number. The serial number code function converts each 32 bit serial number into hex ie. the same function is called 3 times. It sure looks like its in the HidD_Get* call. I see the same issue when I use the "USB Port Monitor" utility.

Do I assume there are no settable size limits in the firmware?

SD

[Jan Axelson]

What is bLength in the device's string descriptor?

Jan

[rallysjd]

CustomHID_DeviceDescriptor = 18
CustomHID_ConfigDescriptor =  41
CustomHID_ReportDescriptor = 219
CustomHID_StringVendor = 46
CustomHID_StringProduct = 36
CustomHID_StringSerial = 52

All these are correctly initialized. CustomHID_StringVendor[46] had 45 init bytes only, but correcting this had no effect, as expected (If I have excess initializers the compiler complains of course). Vendor and SerialNumber strings are truncated as before.

Are there even-byte alignment issues with the various descriptors? If there was I'd expect to see some leading hex chars to be truncated, not when the second hex value is parsed into the serial string.

SD

[Jan Axelson]

bLength should be the number of Unicode chars * 2 plus 1 byte for bLength and 1 byte for bDescriptorType (03h). So the string descriptor's bLength should be 50 (no null termination).

Post the full string descriptor here.

A protocol analyzer will tell you how many bytes the host is requesting and how many the device is sending.

Jan

[rallysjd]

OK, I've found out what's happening, but don't know why.
 
My serial string length is 52 = 25 unicode chars + size and type bytes.  In the first case  the serial string was initialized with 13 chars + NULL. ( 14 wchars...). The actual 24 wchar serial number was copied to the string in the call to CustomHID_init(). The reported serial number was 14 chars (there that 14 again...).

In the second case, I initialized all 25 wchars in the string with printable characters. Loading the new device results in Windows updating the device's driver, because there is a new (default?) serial number. The actual serial number is copied as before, and the correct 24 wchar serial number (and vendor string) is now reported correctly. A second board with the earlier f/w still shows the truncated serial and vendor IDs.

My theory is that when Windows first enounters the device, it stores the serial number length+NULL, and later when HidD_Get* is called, it returns only the 14 characters. In some fashion this incorrect length is messing up the vendor string length too.

So ... for me the cure is to fully init all the strings with valid chars, not all NULL.

Comments?

SD

[Jan Axelson]

Yes, the host may request string descriptors at any time, including during enumeration.

Jan