STM32MP257DAK3 USB3DR not working in peripheral mode under Linux

[Nikolai_Navrotski]

Hi, ST Community!

We are developing a device based on the STM32MP257DAK3 processor.

The firmware is built using Yocto (Scarthgap release) with Linux kernel 6.6 from ST and the meta layers meta-st-openstlinux and meta-st-stm32mp.

The device includes a USBPD controller (MAX77958) that is managed by an external microcontroller. This setup is intended to allow USB charging independently of the main processor.

Goal:

We want to enable USB3DR in USB 2.0 peripheral mode (to use USB gadget / Ethernet over USB under Linux).

In U-Boot and DFU mode, USB works fine

→ The PC sees the device

→ Data transfers are successful

→ USB traffic is visible on the oscilloscope

After Linux boots:

→ The PC doesn’t detect the USB device

→ USB lines are completely idle (both lines at 0V)

→ usb1 interface appears in ifconfig

→ No errors in dmesg

Device Tree config (from ST documentation):

&usb3dr {
	status = "okay";

	dwc3: usb@48300000 {
		maximum-speed = "high-speed";
		role-switch-default-mode = "peripheral";
		usb-role-switch;
	};
};

Relevant log (dmesg | grep -i usb):

[    0.085159] usbcore: registered new interface driver usbfs
[    0.085196] usbcore: registered new interface driver hub
[    0.085229] usbcore: registered new device driver usb
[    0.201783] usbcore: registered new interface driver usb-storage
[    0.202116] usbcore: registered new device driver onboard-usb-hub
[    0.212602] usbcore: registered new interface driver usbhid
[    0.212615] usbhid: USB HID core driver
[    0.300337] scmi-regulator scmi_dev.6: Regulator vdd3v3_usb registered for domain [20]
[    0.362092] usb-stm32-dwc3 42080000.bus:usb@48300000: configured in usb2 mode
[    0.365389] usb-stm32-dwc3 42080000.bus:usb@48300000: Enabling runtime PM for inactive device with active children
[    0.411847] ehci-platform 482f0000.usb: EHCI Host Controller
[    0.411881] ehci-platform 482f0000.usb: new USB bus registered, assigned bus number 1
[    0.411994] ehci-platform 482f0000.usb: irq 70, io mem 0x482f0000
[    0.430691] ehci-platform 482f0000.usb: USB 2.0 started, EHCI 1.00
[    0.431368] hub 1-0:1.0: USB hub found
[    0.686236] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    0.847091] hub 1-1:1.0: USB hub found

What we’ve tried:

• Set peripheral-only mode in Device Tree
• Tried dual-role, but it seems to require M33/TF-M firmware — not using it at the moment
• Loaded g_ether manually — didn’t help
• Configured usb-role-switch and connector nodes
• Verified power supplies and regulators (e.g. vdd3v3_usb) are OK

Questions:

• Is it possible to use USB3DR in peripheral-only mode without using Cortex-M33 firmware (TF-M)?
• If yes, what’s the correct way to set it up?

Any help or suggestions would be greatly appreciated!

Best regards,

Nikolai

[Erwan SZYMANSKI]

Hello @Nikolai_Navrotski ,
I confirm that in peripheral mode only, M33 FW for Power Delivery is not mandatory (https://wiki.st.com/stm32mpu/wiki/USB3DR_device_tree_configuration#DT_configuration_example_as_USB2-speed_only_USB3DR_in_Peripheral_mode--with_micro-B-28ID_left_unconnected-29_or_Type-C_connector)

Can you give a bit more information concerning the script you launch to configure your USB gadget ?

Kind regards,
Erwan.

[Nikolai_Navrotski]

Hello, @Erwan SZYMANSKI 
Thank you for your reply!
We are using script from meta-st-openstlinux without any changes ( https://github.com/STMicroelectronics/meta-st-openstlinux/blob/scarthgap/recipes-bsp/tools/usbotg-gadget-config/stm32_usbotg_eth_config.sh )

Best regards,
Nikolai

[Erwan SZYMANSKI]

Hello @Nikolai_Navrotski ,
I took the STM32MP257F-DK board to test the same device tree as you have.
By removing the M33 firmware running, I do not see any issue to make the gadget launch.

Please verify the following points:

Board $> stm32_usbotg_eth_config.sh stop
Board $> stm32_usbotg_eth_config.sh start

Check if you have specific error raised here (module libcomposite not launched for example).
If not, check if you have the usb0 interface up with ifconfig

Be careful, it seems that the default IP address attribution is commented in the gadget script:

    interfacename=$(cat ${d}/functions/${func_eth}/ifname 2> /dev/null)
    if [ -z "${interfacename}" ];
    then
        interfacename=usb0
    fi
    # ifconfig ${interfacename} $IP netmask $NETMASK
    ifconfig ${interfacename} up

You can uncomment the line to let the default IP address setting. You can do it manually if you want to set it yourself.

Kind regards,
Erwan.

[Nikolai_Navrotski]

Hello, @Erwan SZYMANSKI ,

Thank you for checking this on the STM32MP257F-DK board and confirming that the gadget should work even without the M33 firmware.

I followed your instructions and verified the following:

• I ran stm32_usbotg_eth_config.sh stop and then start — no errors appeared.

• The libcomposite module is loaded.

• The usb0 interface is up, and ifconfig shows:

usb0 Link encap:Ethernet HWaddr 8E:30:19:40:4E:49
inet addr:192.168.7.2 Bcast:192.168.7.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

So the interface seems properly configured and active.

However, my host PC still does not detect the USB device at all. There's no new interface or network gadget showing up on the host side.

Could this still be related to some hardware configuration, or USB role settings in the device tree?

Best regards,
Nikolai

---

[Nikolai_Navrotski]

Hello, @Erwan SZYMANSKI 

Thank you for your help and suggestions.

I’ve managed to resolve the issue. The root cause was that I was using a custom Device Tree binary, but it wasn't being properly loaded by U-Boot during the boot process. As a result, the USB gadget was not initialized as expected.

Once I corrected the Device Tree handling in U-Boot and ensured that my custom .dtb was correctly loaded and used during boot, the USB gadget interface (usb0) appeared and started working as intended.

Thanks again for your support!

Best regards,
Nikolai