Is there an example for the x-cube-azrtos-l4 for winusb

[MikeAtETI]

Is there an example for the x-cube-azrtos-l4 usbx stack showing how to implement the additional string descriptions and GET_OS_FEATURE_DESCRIPTOR features to allow an HID device to appear as WinUSB?

[MikeAtETI]

Looks like you can extend the string descriptors for the extra descriptor extending USBD_Get_String_Framework for the extra string descriptor (0xEE)

There looks to be a function _ux_device_stack_microsoft_extension_register that may be where you hook the function descriptor bits in, but its unclear how to use it.

[mohamed.ayed]

Hi @MikeAtETI​  We don't provide yet WinUSB example or template in our Azure RTOS packages

[MikeAtETI]

To help those who might find by searching, we've made the following modifications and it now shows as WinUSB.

See WCID Devices · pbatard/libwdi Wiki (github.com) for more implementation info

In MX_USBX_Device_Init, after ux_device_stack_class_register and its return check add:

_ux_device_stack_microsoft_extension_register(USB_REQ_GET_OS_FEATURE_DESCRIPTOR, CustomMicrosoftRequestHandler);

The following is the CustomMicrosoftRequestHandler:

#define CustomHID_TYPE_OS_FEATURE_EXT_PROPERTIES 5
#define CustomHID_TYPE_OS_FEATURE_EXT_COMPAT_ID 4
 
USBD_CompatIDDescStruct USBD_CompatIDDesc = { sizeof(USBD_CompatIDDesc), 0x0100, 0x0004, 0x01, {0}, 0x00, 0x01, "WINUSB", {0}, {0} };
USBD_ExtPropertiesDescStruct USBD_ExtPropertiesDesc = { sizeof(USBD_ExtPropertiesDescStruct), 0x0100, 0x0005, 0x0001,\
136, 7,\
42, {'D', 'e', 'v', 'i', 'c', 'e', 'I', 'n', 't', 'e', 'r', 'f', 'a', 'c', 'e', 'G', 'U', 'I', 'D', 's'},\
80, \
{'{', '4', '6', '7', '1', '4', '8', 'F', 'B', '-', '3', 'A', '6', '1', '-', '4', '1', '0', '2', '-', '8', '8', '5', '1', '-', 'B', '1', '3', '5', 'C', '5', '7', '5', '2', '2', '4', '2', '}', 0, 0 } };
 
UINT CustomMicrosoftRequestHandler(ULONG request, ULONG request_value, ULONG request_index, ULONG request_length, UCHAR *pData, ULONG *pApplication_data_length)
{
	if (request == USB_REQ_GET_OS_FEATURE_DESCRIPTOR)
	{
		switch(request_index)
		{
		case CustomHID_TYPE_OS_FEATURE_EXT_COMPAT_ID:
			memcpy(pData, &USBD_CompatIDDesc, sizeof(USBD_CompatIDDescStruct));
			*pApplication_data_length = sizeof(USBD_CompatIDDescStruct);
			return UX_SUCCESS;
			break;
		case CustomHID_TYPE_OS_FEATURE_EXT_PROPERTIES:
			memcpy(pData, &USBD_ExtPropertiesDesc, sizeof(USBD_ExtPropertiesDescStruct));
			*pApplication_data_length = sizeof(USBD_ExtPropertiesDescStruct);
			return UX_SUCCESS;
			break;
		}
	}
	return UX_ERROR;
}

and this is the addition in ux_device_descriptors.c

uint8_t CustomHID_StringWinUSB[18] = { 0x12, 0x03, 'M',0,'S',0,'F',0,'T',0,'1',0,'0',0,'0',0, USB_REQ_GET_OS_FEATURE_DESCRIPTOR, 0 };

and then add this to USBD_Get_String_Framework:

// Microsoft OS Descriptor
 USBD_string_framework[count++] = USBD_LANGID_STRING & 0xFF;
 USBD_string_framework[count++] = USBD_LANGID_STRING >> 8;
 USBD_string_framework[count++] = 0xEE;
 USBD_Desc_GetString((uint8_t *)CustomHID_StringWinUSB, USBD_string_framework + count, &len);
 count += len + 1;

[DGabc.1]

Hello,

Thank you for this sample.

But I do not think it will work with USBX. Specifically, if you look at ux_device_stack_descriptor_send(), the part that handles UX_STRING_DESCRIPTOR_ITEM, it assumes that the string framework string value is a ASCII string and converts it to UNICODE. That means CustomHID_StringWinUSB will get extra zeros inserted, which will make it invalid.

I am looking at it, as if it is used directly with USBX.

Thank you,

D.