STM32CubeU5
STM32CubeU5 copied to clipboard
UX Device Class VIDEO Device Descriptor class
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)
- Indicate the global behavior of your application project
- List the modules that you suspect to be the cause of the problem (Drivers, BSP, MW...)
- Describe the use case that generates the problem
- 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.
Why is this invalid?
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:
https://github.com/STMicroelectronics/STM32CubeU5/blob/adf6b6ecba7056fb65753b41a970329c305523ff/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_CDC_ACM/USBX/App/ux_device_descriptors.c#L381-L383
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:
https://github.com/STMicroelectronics/STM32CubeU5/blob/adf6b6ecba7056fb65753b41a970329c305523ff/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_CDC_ACM/USBX/App/ux_device_descriptors.c#L431-L437
I hope this makes things clearer. Do not hesitate otherwise.
With regards,
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.
I understand better your point. I'll give it another try with STM32CubeMX and let you know. Thank you for the clarification.
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,
ST Internal Reference: 218137
Hello @builder60,
I hope you are fine. Upon further analysis, it appears that the issue is indeed at STM32CubeMX level. A fix will be implemented so when the video class is selected, the ux_device_descriptors.c file will be correctly generated. Currently, I cannot share a release date of this fix.
Now, since this issue does not concern the files provided within this repository, but rather the generation tool, please allow me to close it. Thank you for your understanding and thank you again for having reported this point.
With regards,
Hello @builder60,
Just for info, this fix should be part of version 6.16.0 of STM32CubeMX.
With regards,