STM32MP257F-DK: USB3DR peripheral mode only links at High-Speed (SuperSpeed works in host mode), official image
# STM32MP257F-DK: USB3DR in peripheral (device) mode only links at High-Speed
Report prepared for submission to STMicroelectronics (ST Community / support).
## 1. Summary
On an STM32MP257F-DK running the official ST OpenSTLinux image, the Type-C port (USB3DR + COMBOPHY)
enumerates SuperSpeed (5 Gbps) devices correctly when the board is **host**. When the same board is
**peripheral (gadget)**, the link always trains to **High-Speed (480 Mbps)** and never to SuperSpeed.
This happens against a PC USB 3.0 port and against a second identical DK, with both Type-C plug
orientations, and with a cable verified to carry SuperSpeed lines.
Device tree, COMBOPHY and DWC3 glue configuration follow the ST wiki exactly, and the M33
`USBPD_DRP_UCSI` firmware logs show the USB3 switch (PH2/PH3) being driven for both orientations.
**Question for ST:** is SuperSpeed in peripheral mode supported on the STM32MP257F-DK Type-C port with the
stock `USBPD_DRP_UCSI` firmware? If yes, what is missing in our setup?
## 2. Environment
| Item | Value |
|---|---|
| Boards | 2x STM32MP257F-DK (Discovery Board) |
| Image | Official ST OpenSTLinux, `5.0.17-openstlinux-6.6-yocto-scarthgap-mpu-v26.06.10` (distro: openstlinux-weston) |
| Kernel | Linux 6.6.129 (also reproduced with 6.6.116 in a Yocto build of the same BSP) |
| Device tree | stock `st,stm32mp257f-dk` (no board-level changes) |
| M33 firmware | `USBPD_DRP_UCSI` from STM32CubeMP2 v1.3.0 (`SRCREV 38732d24f8928af2dbcd9491f92390efbaec78d6`) |
| Kernel config | `CONFIG_USB_DWC3=y`, `CONFIG_USB_DWC3_DUAL_ROLE=y`, `CONFIG_USB_DWC3_STM32=m`, `CONFIG_PHY_STM32_COMBOPHY=m` |
| Gadget | configfs `g1`, NCM function, created by stock `/usr/sbin/stm32_usbotg_eth_config.sh` |
| PCIe | disabled (`pcie@48400000` and `pcie-ep@48400000` are `disabled`), COMBOPHY node `okay` |
## 3. Device tree (matches ST wiki, section "DT configuration example as USB3-speed USB3DR, with Type-C connector")
```dts
&combophy {
st,ssc-on;
status = "okay";
};
&usb3dr {
status = "okay";
dwc3: usb@48300000 {
phys = <&usb2_phy2>, <&combophy PHY_TYPE_USB3>;
phy-names = "usb2-phy", "usb3-phy";
usb-role-switch;
port {
dwc3_ep: endpoint {
remote-endpoint = <&typec_ep>;
};
};
};
};
/* typec@35 is provided by the M33 through i2c_rpmsg; its connector port points to dwc3_ep */
```
- No `dr_mode` (default `otg`), no `maximum-speed`, no `role-switch-default-mode`.
- Verified on the running board:
- `dmesg`: `usb-stm32-dwc3 42080000.bus:usb@48300000: configured in usb3 mode`
- `/sys/class/udc/48300000.usb/maximum_speed` = `super-speed`
- `/sys/kernel/config/usb_gadget/g1/max_speed` = `super-speed-plus`
- `DCFG` speed field = 4 (SuperSpeed)
## 4. Observations
### 4.1 Board as host: SuperSpeed works
A USB 3.0 SD card reader (Genesys Logic `05e3:0749`) plugged into the Type-C port, board in host mode:
```
usb 3-1: new SuperSpeed USB device number 2 using xhci-hcd
usb-storage 3-1:1.0: USB Mass Storage device detected
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
```
This was reproduced on both boards, so COMBOPHY, the USB3 PHY path, the FUSB340 switch and the Type-C
connector are functional in host mode.
### 4.2 Board as peripheral: always High-Speed
Peer is either a PC USB 3.0 port or the second DK in host mode. Result is identical in all cases:
```
UDC state : configured
UDC current_speed : high-speed
DSTS : 0x008b9b48 (CONNECTSPD [2:0] = 0 -> High-Speed)
link_state : Sleep
```
On the host side the NCM device appears on the USB 2.0 root hub only:
```
usb 2-1: new high-speed USB device number 2 using xhci-hcd
cdc_ncm 2-1:1.0: register 'cdc_ncm' ... CDC NCM
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 001: Dev 002, If 0, Class=Communications, Driver=cdc_ncm, 480M
```
Bus 003 (5000M) shows no device.
### 4.3 Both plug orientations were tested
The M33 firmware was instrumented to write to a remoteproc trace buffer (`cm33_log`, read from
`/sys/kernel/debug/remoteproc/remoteproc0/trace0`). Only logging was added; the Type-C/USB3-switch
logic in `USBPD_DPM_UserCableDetection` is unchanged. Log for two attach events with the plug flipped:
```
[00000.847]DPM UserInit
[00000.986]ATTACH state=2 cc=2 pwr=0 data=0 PH2(OE)=0 PH3(S)=1
[49465.336]DETACH state=1 PH2(OE)=1
[49468.855]ATTACH state=2 cc=1 pwr=0 data=0 PH2(OE)=0 PH3(S)=0
```
- `cc=2` -> PH3 (S) = 1, `cc=1` -> PH3 (S) = 0, PH2 (OE) = 0 in both cases, exactly as coded in the
stock firmware (OE low = switch enabled, S selects CC1/CC2 side).
- `pwr=0 data=0` -> Sink / UFP, consistent with Linux `power_role = source [sink]`, `data_role = host [device]`.
- Link speed stayed High-Speed in both orientations.
### 4.4 Other observed state
- `/sys/class/typec/port0` and `port0-partner` are present (Type-C connection and PD are working).
- RPMsg channels `rpmsg-intc` and `rpmsg_i2c` are created; `ucsi`/Type-C path is healthy.
- PH2/PH3 report `NO ACCESS` in Linux pinctrl: RIF assigns them to CID2 (M33). This is expected.
- Standard configfs gadget script writes `bcdUSB = 0x0200`. We also tested `0x0310`; the kernel reports
`0x0210` while linked at High-Speed. This does not change the link speed.
## 5. What was ruled out
| Hypothesis | Result |
|---|---|
| Device tree missing COMBOPHY / `phys` not including USB3 | Not the case, matches ST wiki |
| `maximum-speed = "high-speed"` or USB2-only glue mode | Not set; log says `configured in usb3 mode` |
| COMBOPHY used by PCIe | PCIe controllers are `disabled` |
| Gadget limited to USB 2.0 | `max_speed=super-speed-plus`, UDC `maximum_speed=super-speed` |
| Cable without SuperSpeed lines | Same cable gives 5000M when the board is host; also tried a second cable |
| One plug orientation / wrong switch side | Both CC1 and CC2 tested, same result |
| Specific peer | PC USB 3.0 port and a second DK both give High-Speed |
| Board-specific hardware fault | Reproduced on two boards; official image used |
| M33 not driving the USB3 switch | Trace log shows PH2/PH3 set for each attach |
| Customer Yocto changes | Reproduced with the official ST image |
## 6. Questions
1. Is SuperSpeed in USB3DR **peripheral** mode supported on the STM32MP257F-DK Type-C port with
`USBPD_DRP_UCSI` (CubeMP2 v1.3.0)? Is there a known limitation or erratum (DWC3 device-mode link
training, COMBOPHY RX termination, FUSB340 routing in UFP role)?
2. Is any additional setup required beyond the ST wiki USB3DR/COMBOPHY pages, for example a DWC3 quirk
(`snps,dis_u3_susphy_quirk`, `snps,dis_rxdet_inp3_quirk`, ...), `USB3DRCR`/syscfg bits, or a PHY
initialization step specific to the device role?
3. Does the M33 firmware need to do anything for the device role other than setting PH2 (OE) and PH3 (S)?
For example, does the switch require a different OE/S polarity or a different timing when the port is a
sink/UFP?
4. Is there a validated reference (ST demo, application note) showing the DK enumerating as a SuperSpeed
gadget on a USB 3.0 host?
## 7. Reproduction steps
On the board in peripheral mode with the stock image:
```sh
# Type-C partner = USB 3.0 host (PC port, or another DK with: echo host > /sys/kernel/debug/usb/48300000.usb/mode)
cat /sys/kernel/debug/usb/48300000.usb/mode # device
cat /sys/class/udc/48300000.usb/maximum_speed # super-speed
cat /sys/class/udc/48300000.usb/current_speed # high-speed <-- expected: super-speed
grep DSTS /sys/kernel/debug/usb/48300000.usb/regdump # CONNECTSPD = 0 (HS), expected 4 (SS)
cat /sys/kernel/debug/usb/48300000.usb/link_state # Sleep
```
## 8. Attachments to include when submitting
- `dmesg` from boot and from the plug event
- `lsusb -t` on both host and device side
- Full `regdump` from `/sys/kernel/debug/usb/48300000.usb/regdump`
- M33 `trace0` log (section 4.3)