cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L073- multiple USB device interfaces

lprzenioslo
Associate II

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?

0693W00000WL5f5QAD.pngBut 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.

12 REPLIES 12

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​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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
Lead III

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.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
lprzenioslo
Associate II

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
Chief II

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

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.

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
Lead III

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.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice