Status of CubeMX support for USB_DEVICE CompositeBuilder
Hello ST community,
I am trying to understand the current support status of USB composite devices when using the classic stm32-mw-usb-device middleware.
I know that the classic USB Device middleware already contains `CompositeBuilder`, and I have seen ST tutorials using it to build composite devices. For example, the STM32H5 CDC + HID tutorial and the dual CDC ACM tutorial.However, those tutorials still require a lot of manual integration: editing `usbd_conf.h`, editing `usbd_conf.c`, manually writing class registration code, and manually maintaining the generated `USB_DEVICE` folder. This is quite fragile because future CubeMX regeneration can overwrite important changes.
For newer stacks, USBX seems to have much better composite support, where all the relevant code for composite could be generated by CubeMX.
My questions are:
1. Is there currently any STM32CubeMX-supported MCU package that can directly generate a classic `stm32-mw-usb-device` composite project using `CompositeBuilder`, including descriptors, endpoint lists, class registration, interface callback registration, and class data storage?
2. If yes, which MCU series/package/CubeMX version should be used as the reference?
3. If no, is `CompositeBuilder` intended to remain a manually integrated advanced feature of the classic middleware?
While manually building a CDC + Custom HID composite device, I also found a few design issues that make manual integration more error-prone:
First, the classic middleware template exposes:
#define USBD_malloc (void *)USBD_static_malloc
void *USBD_static_malloc(uint32_t size)
{
UNUSED(size);
static uint32_t mem[(sizeof(USBD_HID_HandleTypeDef) / 4) + 1];
return mem;
}This is unsafe for composite devices. For example, CDC and HID may both allocate their class handles:
hcdc = (USBD_CDC_HandleTypeDef *)USBD_malloc(sizeof(USBD_CDC_HandleTypeDef));
hhid = (USBD_CUSTOM_HID_HandleTypeDef *)USBD_malloc(sizeof(USBD_CUSTOM_HID_HandleTypeDef));The application expects two different objects, but the template allocator can return the same address, so one class overwrites the handle of another. Since the number of classes and class handle sizes are known at compile time, explicit static per-class storage seems safer and simpler than a fake dynamic allocation API.
Second, for a composite device using IAD, the device descriptor fields appear to be important on Windows:
0xEF, /* bDeviceClass */
0x02, /* bDeviceSubClass */
0x01, /* bDeviceProtocol */Leaving the descriptor as a single CDC-style device:
0x02, /* bDeviceClass */
0x02, /* bDeviceSubClass */
0x00, /* bDeviceProtocol */can cause enumeration problems. It would be helpful if CubeMX or the middleware template automatically generated `0xEF/0x02/0x01` when `USE_USBD_COMPOSITE` and IAD are enabled.
So I would like to ask:
- Did I miss an official automatic generation path for classic USB middleware composite devices? Is the current manual workflow expected?
- Would an Github issue against `stm32-mw-usb-device` for composite-safe class data allocation and automatic device descriptor generation be welcome?
Thank you.
