stm32_common: Add USB OTG FS/HS usbdev peripheral driver#12556
stm32_common: Add USB OTG FS/HS usbdev peripheral driver#12556aabadie merged 16 commits intoRIOT-OS:masterfrom
Conversation
a07d975 to
83043b2
Compare
11ced48 to
ddccb4a
Compare
|
Almost done here, I've tested this myself on the nucleo-f401re and the nucleo-f446re with a jumper wired USB cable. Both CID versions should work and both the FS and the HS peripheral work (in FS mode with the built-in phy). With the HS phy, both DMA and non-DMA is functional. I have not yet tested isochronous transfers. |
ddccb4a to
d05e0e4
Compare
77a8556 to
0155807
Compare
47630d8 to
69dc829
Compare
|
Ready for review! I won't be force pushing anymore to this branch unless instructed otherwise. I'm going to test isochronous transfers at some point, but I won't consider it blocking for this PR as it is not used within RIOT-provided USB functionality at the moment. Still waiting for #12579 though. :) |
|
I'm carefully going to claim that isochronous transfers work. I have a small test setup where I can at least get the events from the transfer and receive events for the transfers. I also receive correct transfer lengths, I'm only haven't tested the content of the transfer yet. |
6f73cba to
b3c6be7
Compare
|
Rebased now that #12579 is merged, no longer waiting for other PRs |
b440a0b to
7df935e
Compare
|
Squashed after offline approval from @aabadie. |
cpu/stm32_common/Makefile.dep
Outdated
| USEMODULE += stm32_common stm32_common_periph | ||
|
|
||
| ifneq (,$(filter periph_usbdev,$(FEATURES_USED))) | ||
| USEMODULE += xtimer |
There was a problem hiding this comment.
| USEMODULE += xtimer | |
| USEMODULE += xtimer |
Looks like there's a tab here
7df935e to
1f5340c
Compare
aabadie
left a comment
There was a problem hiding this comment.
ACK! Now let's wait for Murdock (which is quite busy)
|
All green, let's go ! |
|
Thanks! |
|
Good job with this PR @bergzand ! |
Contribution description
This PR adds an USBdev driver for the ST (synopsys). It is used with the STM32F2, STM32F4, STM32F7 and STM32H7 devices. The STM32F1 and STM32F3 devices unfortunately use a different device type.
The goal is to support the both the full speed and the high speed version in a single driver, the differences between the two are minimal and drivers from other project are able to combine the two instances too.
The peripheral itself has a 'Core ID' register containing a version number-like value. So far I've identified 2 different iterations for both the FS and the HS devices. They have slightly different register flags and behave slightly different in some cases. The crude method to detect the version is to check if certain register flag definitions are defined.
It is assumed that when both the FS and the HS peripheral is available on a single device, both are of the same version.
0x1x00: 4 FS endpoints, 6 HS endpoints (f401, f411…)0x2x00: 6 FS endpoints, 9 HS endpoints (f446, f7xx…)Testing procedure
examples/usbus_minimalshould work when addingxtimer.tests/usbus_cdc_ecmshould work with cdcecm: only activate OUT endpoint after interface selection #12533 cherry-picked.tests/usbus_cdc_acmshould work with cdcacm: Activate data out endpoint on DTE present signal #12536 cherry-picked.Issues/PRs references
One of the remaining issues with the driver is that it requires xtimer (or a different solution) to sleep between one of the register modifications.
depends on
#12534,#12533,#12536and#12579TODO:
periph_usbdevis used.#defineTest isochronous transfersNote
@chrysn, @basilfx: FYI The EFM32 devices seem to use an identical IP block from Synopsys, only the serialization phy seems to be different.