UX Device Class VIDEO Device Descriptor class

[builder60]

Caution

The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post your report to the ST Community in the STM32 MCUs dedicated page.

Describe the set-up

NUCLEO-U5A5ZJ-Q
STM32CubeMX v6.12.1

Describe the bug (skip if none)

Select USBX->UX Device HS->Device Class HS->VIDEO and generate code.

The generated file USBX/App/ux_device_descriptors.c (line 381) creates a device descriptor with bDeviceClass = 0, bDeviceSubClass = 0, and bDeviceProtocol = 0.

Please refer to section 3.2 Device Descriptor of "UVC v1.5 Class specification" available at https://www.usb.org/document-library/video-class-v15-document-set

Extracted from that document:
"...since the device uses an Interface Association
Descriptor in order to describe the Video Interface Collection, it must set the bDeviceClass,
bDeviceSubClass and bDeviceProtocol fields 0xEF, 0x02 and 0x01 respectively. This set of
class codes is defined as the Multi-interface Function Class codes."

Perhaps line 432 of the ux_device_descriptors.c file should also consider the presence of the IAD descriptor?

How to reproduce the bug (skip if none)

1. Indicate the global behavior of your application project
2. List the modules that you suspect to be the cause of the problem (Drivers, BSP, MW...)
3. Describe the use case that generates the problem
4. How we can reproduce the problem

Additional context

If you have a first analysis, an enhancement, a fix or a patch, thank you to share your proposal.

Screenshots

If applicable, add screenshots to help explain your problem.

[builder60]

Why is this invalid?

[ALABSTM]

Hi @builder60,

Thank you for your post. You are right about the fact that, within the function USBD_Device_Framework_Builder(), and precisely at lines 381 to 383 of the generated file ux_device_descriptors.c, the mentioned descriptor's attributes are set to 0x00.

This is also the case of the applications provided with the STM32CubeU5 firmware, as shown in the example below:

STM32CubeU5/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_CDC_ACM/USBX/App/ux_device_descriptors.c

Lines 381 to 383 in adf6b6e

	pDevDesc->bDeviceClass = 0x00;
	pDevDesc->bDeviceSubClass = 0x00;
	pDevDesc->bDeviceProtocol = 0x00;

However, if you have a look a couple of lines after, you will notice that these attributes are updated in compliance to the document you mentioned, as shown below:

STM32CubeU5/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_CDC_ACM/USBX/App/ux_device_descriptors.c

Lines 431 to 437 in adf6b6e

	/* Check if there is a composite class and update device class */
	if (pdev->NumClasses > 1)
	{
	pDevDesc->bDeviceClass = 0xEF;
	pDevDesc->bDeviceSubClass = 0x02;
	pDevDesc->bDeviceProtocol = 0x01;
	}

I hope this makes things clearer. Do not hesitate otherwise.

With regards,

[builder60]

The update does not happen if there is only one class as in the case of the VIDEO class. The VIDEO class requires the settings because there is more than one interface (Video Control Interface + Video Stream Interface) which requires IAD.

[ALABSTM]

I understand better your point. I'll give it another try with STM32CubeMX and let you know. Thank you for the clarification.

[ALABSTM]

Hi @builder60,

After further analysis, it looks like the ux_device_descriptors.c file is some kind of template used by STM32CubeMX. Hence, if it is confirmed there is some fix or update to do, it is at the level of that template, not the tool itself.

I forwarded your report to our development teams. Let's wait for their feedback and see.

With regards,

[ALABSTM]

ST Internal Reference: 193901