Pm3 Firmware And Get_descriptor Device Request

[old] haboustak · Post by **[old] haboustak** » January 28th, 2005, 6:43 pm

I'd really like to see cross-platform PM3 development, and so I've been working with the PM3 directly using the USB APIs to see how things work. I don't have a decent USB Analyzer (yet $$$) and so it's been slow going. I did come across one interesting thing that doesn't completely make sense. When using the WinDDK API HidD_GetManufacturerString() you supply the API with a unicode (wchar) character buffer and the length of that buffer. The length gets sent to the PM3 via the USB spec in the 2-byte field "wLength". My test code kept failing and I couldn't figure out why. I think the answer may be that the firmware of the PM3 is not using the high-order byte of that field. In my test application, I was using a wchar buffer of length 256, which creates a buffer 512 bytes long (2 bytes per unicode character). wchar_t unicodeBuffer[256]; 512 in hex is 0x02 0x00 (little endian), and so the USB wire should have "0x00 0x02" for wLength. When I send this packet, the PM3 returns an empty string for the Manufacturer. Presumably, because it is only using the low-order byte and that byte is 0x00. When I decrease my buffer to 255 characters (510 bytes), the PM3 works correctly. 510 is 0x01 0xFE (little endian). The PM3 agrees that the Manufacturer Name will fit in 0xFE bytes and returns the proper value. (Concept2) I'm not sure if that's actually the case or not, as I don't have an analyzer and this is all from reading specs and sending test data not from looking at the actual device. But in my case, if the low-order byte of wLength contains less than the length of the requested device string on the PM3, the PM3 refuses to send back the data even if the 16-bit length is large enough. This probably isn't a critical error, because I think I read that the maximum length of a USB device string is 126 characters. Still, it seems like a bug if the firmware only works with the low-order byte of the 16-bit integer. Sorry if I am completely off base here, I'm just getting started. e.g. wchar_t unicodeBuffer[255] (works ... 0x01 0xFE) wchar_t unicodeBuffer[256] (fails ... 0x02 0x00) wchar_t unicodeBuffer[306] (works ... 0x02 0x64)

[old] mlyons · Post by **[old] mlyons** » February 14th, 2005, 11:06 am

I am the PM3 firmware developer. You are correct in your observation about descriptor lengths greater than 255 characters. The current PM3 firmware is not "honoring" the fact that wLength is a 2-byte value so that any descriptor length that exceeds 255 characters is incorrectly handled. Windows platforms don't ask for anything greater than 255 characters in length so the issue was never identified. ALl the PM3 descriptors are significantly less than 255 characters wo this should not be a limiting factor. The next release of PM3 firmware will fix this issue. Thanks for the feedback and keep plugging away.

[old] haboustak · Post by **[old] haboustak** » February 17th, 2005, 10:56 am

Great! I completely agree that it's in no way a critical error and it doesn't affect the current functioning of the PM3. I'm really glad to hear that the next version will be compliant though, because you never know when your OS will change on you. (particularly USB on OS X, as I've found recently) As the firmware stands currently, I've been quite successful at communicating with the PM3 on a Mac running OS X, which should be a testament to the small number of bugs (if any) existing in the USB component of the firmware. I hope to have an application/user-land driver soon that demonstrates and also tests the ability to control the PM3 on a Mac. I'll keep you posted if I can uncover anything else. Mike