STM32L073- multiple USB device interfaces

[lprzenioslo]

Hello,

We are currently evaluating the STM32L073 series in terms of the possibility to configure the USB device as either:

• 3x interfaces, all serial (COM) ports.
• 3x interfaces, 2x serial (COM) port and 1x mass storage device.

In the STM32 studio I have noticed initially that in theory there is the possibility to define from 1 to 255 interfaces?

But then when set the USBD_MAX_NUM_CONFIGURATION and USBD_MAX_NUM_INTERFACES to 2, I had no way to configure more than 1 interface in the software GUI. I right now don't have the hardware to check that physically.

Are multiple USB interfaces possible for this one? I would appreciate all help.

[Tesla DeLorean]

One connection

Composite Device

Described via Descriptors

Limited by available End-Points

USB can have 255 of these, as I recall STs limited to about 8, so 0 and 1 thru 7​

[lprzenioslo]

Hi @Community member​ , thank you for the answer.

So just to make sure I understand your answer- the described functionality is possible to accomplish by this certain MCU? If yes, then it seems that the STM32 studio does not fully support it?

[gbm]

What you want to implement is USB Composite Device. ST CubeMX and USB stack does not support composite devices yet, the work is in progress and you may try to study the HAL sources and maybe achieve what you want, since the stack itself is almost ready for it. The ST composite device will be even more complex than what we can see today with single function devices and I feel it will be very hard to use and debug with its infinite levels of nesting and callbacks. Feel warned that most of ST USB examples are incorrect and will at some point hang. There are few alternatives - much simpler and easier to use USB stacks available on the net.

I have implemented many CompDevs using a heavily modified (simplified) ST stack. Now I am in the process of switching to my much simpler stack with greatly reduced (by > 80%) ROM and RAM footprint - already working on F1 and F0 series (basically the same as L0), still some problems on L4/F4.

To see what's possible with a given MCU, count the endpoints required for your device. Control requires 1 ep pair, CDC - 2 pairs, MSC - 1 pair. There are 8 pairs available in L073, so you can do 3xCDC+MSC.

[lprzenioslo]

Hi @gbm​ , thank you for your feedback.

Its good to hear that this is possible. I have some experience with USB on STM32 from the past, but it was always 1 interface per USB. Seems some manual work will be needed then.

[Piranha]

You can get TinyUSB running in a few hours...

https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_msc

Edited by moderating team to adhere to community guidelines

[lprzenioslo]

Hi there,

Thank you for the link. I will definetly check this out, as one of my main issues woth the ST USB stack is that everything is habdled directly in the interrupt routine.

[Piranha]

Yes, that is probably the biggest design flaw, but definitely not the only one.

https://community.st.com/s/question/0D53W00001Ie4WcSAJ/32f417-how-to-block-usbfs-isr-from-a-shared-resource-serial-flash-on-spi

[lprzenioslo]

Wow, and I was initially thinking to do the exact same thing (fool the host by returning busy flags to give me time for getting the actual data in an async way).

Thanks for saving my time.

[gbm]

Can't see anything wrong with ISR-based approach, although probably it should be the user's choice (ISR vs. task/event loop). The real problems are:

• very complex data structures,
• variables mixed with constants - constants occupy RAM
• unnecessary dynamic callbacks - variable function pointers in place of constant,
• big nesting depth - 9 levels in a simple device (max. 4 needed for composite device in a regular implementation)
• lack of boolean data - everything, even bit flags, is handled as 32-bit.

All of this makes the HAL-based device stack unusable, and the planned composite device supports brings even more complications to this already too complex model.

Regarding sharing the SPI Flash - there is a simpler solution - define the Flash access handler as an ISR of the same priority as USB and use software-triggering of interrupts. Many sync problems may be solved this way and it is possible to write the whole firmware without an event loop ("main loop"), using only the event handler ISRs.