Many MCUs from STM32 family happily do support an USB device, but mbed currently supports only some models, namely L4x, F303 and H7x. For my current project I use STM32L152 because besides the USB dev functionality it is ultra-low power, it does support internal EEPROM (like all models from L1 family) which makes it, say, blocking dependency for this current project.
But Mbed does not support usb in STM’s L1 series. This topic stretches at this forum far away into 2016s, when first questions for this support have arisen, but there has been silence all the way long until now. Thats so shame because L1s are so good!
There was apparently some chance to “hack” it back in v.5.15 as described here but it does not apply to current version anymore (or I haven’t find a way, how.)
Unfortunately, I’m quite lame in Mbed internals so after I’ve been struggling for a half of a day, I realized that porting USB for my MCU is above my strenghts. And I’m not alone hoping for this functionality, by far.
So I may try to ask an ultimate question to help deciding this struggle for everyone else like me - Is this support ever gonna be implemented? Is this on some dev roadmap, or we just have to accept that this is never gonna be?
Or - is there any other chance working it around? Had anyone achieved that?
Unfortunately, if there is no viable option for common mortal like me, I’ve been left with two options:
- Change HW design, use non-low-power solution and external eeprom (I don’t want to do that!)
- Port whole project on HAL to STM32CubeIDE where it works (I do not want to do that either. It would be f#ckton of work but unlike porting USB support for my MCU I would be able to do it. And Mbed is great …)
Thank anyone for reactions.
Yes, adding USB support to STM32L1 should be “easy” to enable.
Example for STL32L5:
as @jeromecoutant already hinted, I enabled USB support for the STM32L5 series, and I think there is not much to do for the STM32L1 series. I think I can have a look at it, but it will probably be closer to the end of this week or on the weekend.
Unfortunately I do not have a STM32L1 eval board here, so this would be a dry implementation.
thanks both of you for reactions! You’re right that the PR looks quite easy. I have looked into a little bit but I found out that HAL_rcc structs are different in L1 and do not contain definitions for HSI48, neither the usb peripheral clock. @cjost if you would look into this, that would be awesome… As I looked into this, I don’t dare to write it myslef, however, I could at least test it after on my nucleo-l152, if you wanted.
@rudolfdobias Sorry I took some more time than expected.
I created a draft pull request, could you maybe check it out and test it with your board? The code structure is different between the L1 and L5 series, so I am not sure if just enabling it works.
@cjost Thank you! Now as I see how simple it was I’m sorry that I bothered you. Supposedly I have overlooked that the definition lives in the USBPhyHw.h…
However, I tested the basics (USBSerial so far) with my Nucleo-L152 and it works nice.
So thank you again, I’ll use your branch for development until it’s merged into master.
Thanks for testing and giving me the opportunity to look into it
I will the proceed with the pull request, it might take a week until it is merged.
There are some variations of the STM32L1 where USB still might not work, depending on the main clock used, so maybe some day this will come back to haunt me…
EDIT: as per comment, the actual NUCLEO-L152 board does not have a USB port and therefore cannot have the USBDEVICE flag. However this can be added as a custom target in custom_board.json.