STM32N6 USBX Composite Device: Integrating uvcl (UVC Library) vs. Native USBX for High-Bandwidth ISO with Dual CDC ACM

[jeslet_joy]

Hello ST Community,

I am working on an STM32N6 project where I need to implement a USB composite device containing three distinct classes:

1. CDC ACM Instance 1

2. CDC ACM Instance 2

3. UVC (USB Video Class)

Current Status & Setup:

The dual CDC ACM implementation is fully stable and working properly. I generated the basic framework using STM32CubeMX (.ioc), which handles the initial USBX configuration, the first CDC instance, and sets up the composite device configuration. Following that, I manually added the second CDC ACM instance code to the project.

On top of this working multi-CDC setup, I now want to integrate the Video Class layer. I have enabled the core video class inside the .ioc file and regenerated the code to expand the descriptor framework.

The Challenge:

To support high-bandwidth Isochronous (ISO) streaming for the Video class component, I integrated the uvcl (USB Video Class Library) middleware extracted from the ST Edge AI Getting Started example

The issue started exactly upon adding the uvcl library. I noticed that its initialization function completely wraps the global USB device controller registration (ux_device_stack_initialize) and grabs the only available configuration descriptor for itself. By letting uvcl take over stack initialization this way, it breaks/overwrites my composite device descriptor layout, and my two working CDC instances stop functioning entirely.

My Target Stream Configurations:

The UVC interface needs to support high-bandwidth ISO transfers for YUV422 at 30 FPS across these specific resolutions:

• 224 X 224 @ 30 FPS

• 256 X 256 @ 30 FPS

• 480 X 480 @ 30 FPS

• 640 X 480 @ 30 FPS

• 800 X 480 @ 30 FPS

My Questions:

1. Is high-bandwidth ISO transfer possible using native USBX functions alone, without integrating the uvcl library? Can standard USBX handle multiple transactions per microframe (e.g., wMaxPacketSize set to 0x0C00 or 0x1400 for 2x or 3x 1024 bytes) natively via the standard ux_device_class_video_transmit engine?

2. If uvcl is absolutely mandatory for achieving high-bandwidth ISO on the STM32N6, how can I integrate the library without letting it take over the global USBX initialization? Is there a recommended way to decouple uvcl from the core stack setup so that it only acts as a payload/streaming engine for the specific UVC class instance inside a pre-existing composite device configuration.

Any advice, patches, or architectural guidance on how to stream these YUV422 resolutions over a composite stack without breaking existing CDC paths would be highly appreciated!

[jeslet_joy]

Hi ST Community,

Is there any update on this issue?

I am working on an NUCLEO-N657X0-Q board using USBX to implement a USB Video Class (UVC) device.

Currently, my implementation works correctly when the endpoint maximum packet size is configured as:

#define USBD_VIDEO_EPIN_HS_MPS    1024

With this configuration:

• The USB device enumerates successfully.

• Windows recognizes the UVC device.

• Video streaming works

However, I would like to enable high-bandwidth isochronous transfers (3 transactions per microframe) to support higher-throughput video streaming, for example:

• 224 × 224 @ 30 FPS

• 256 × 256 @ 30 FPS

• 480 × 480 @ 30 FPS

• 640 × 480 @ 30 FPS

• 800 × 480 @ 30 FPS

To achieve this, I changed the endpoint configuration to:

#define USBD_VIDEO_EPIN_HS_MPS    3072

After making only this change, the USB device fails to enumerate. The host no longer recognizes the device, and the enumeration process does not complete. In other words, the device works correctly with USBD_VIDEO_EPIN_HS_MPS = 1024, but changing it to 3072 immediately causes enumeration to fail.

I understand that according to the USB 2.0 specification, the maximum packet size for a high-speed isochronous endpoint is 1024 bytes, and higher bandwidth is achieved by using multiple transactions per microframe (up to three) rather than increasing the packet size itself.

Could someone please clarify the correct procedure for enabling high-bandwidth isochronous endpoints (3 × 1024) on STM32N6 using USBX?

• Is changing USBD_VIDEO_EPIN_HS_MPS sufficient, or are additional descriptor modifications required?

• Does wMaxPacketSize need to be encoded manually for multiple transactions?

• Are there any additional USBX, PCD, or FIFO configurations required to successfully enumerate a high-bandwidth isochronous endpoint?

[FBL]

Hi ​@jeslet_joy 

Thank you for your questions, For HS ISO endpoints, the maximum payload per transaction is 1024 bytes.

You can refer to section 3. Endpoint size and buffering in this article How to select suitable endpoints for your STM32 USB application | Community

For Higher bandwidth operation cannot be achieved by setting the packet size to 3072. 

You should also verify that Alternate Setting 0 on the UVC Streaming interface is configured as zero bandwidth. This is required so that the device can enumerate without reserving isochronous bandwidth too early. The host then selects a non-zero alternate setting when streaming starts.

[jeslet_joy]

Hi ​@FBL 

Thank you for the guidance. I have verified my implementation:

Alternate Setting 0 is already configured as zero bandwidth (bNumEndpoints = 0)

I reviewed the article "How to select suitable endpoints for your STM32 USB application" - it mentions that HS isochronous max packet size is 1024 bytes, but doesn't cover high-bandwidth mode (multiple transactions per microframe).

1. wMaxPacketSize encoding: For 3×1024 bytes/microframe, should wMaxPacketSize be encoded as (2 << 11) | 1024 = 0x1400?
2. FIFO sizing: What TX FIFO size is required for high-bandwidth isochronous at 3×1024 bytes/microframe on STM32N6?
3. Are there any PCD or USBX-specific settings needed?

[FBL]

Hi @jeslet_joy

1. Yes, that is correct, provided that XFERSIZ stays within the controller’s allowed range for periodic IN transfers.
2. MCNT defines how many packets are scheduled in the service interval, so the Tx FIFO sizing must be validated accordingly. The controller must have the full payload available in the FIFO before the IN token is handled; otherwise, the transfer may be incomplete.

3. I raised a ticket about the current implementation of high bandwidth in USBX. For internal reference CDM0064764 

[FBL]

Hi ​@jeslet_joy 

For high bandwidth ISO, wMaxPacketSize must encode:

• bits 10:0 = payload per transaction
• bits 12:11 = additional transactions per microframe

For 3 transactions of 1024 bytes, use wMaxPacketSize = 1024 | (2 << 11)   // 0x1400

So, changing USBD_VIDEO_EPIN_HS_MPS to 3072 directly is not the correct method. ​