Hi Mithlesh,

Is this on the custom board or the EVM? If on the customer board, can the behavior be reproduced on the EVM?

What OS do you run on AM62x? Which version?

Hi Bin,

We are using custom board and not checked with SK EVM so far.

Our system runs on Linux, Kernel version 6.6.15.

Hi Mithlesh,

Does the Linux on AM62x side print any message on the console UART when the issue happens with Windows host?

Please try if you can reproduce the issue on AM62x SK, so that I can replicate it and debug on my side.

Does the issue also happen with Linux host?

Hi Bin,
It might be difficult to reproduce this on the SK EVM. We will check if it can be done with reasonable effort. We lately had some issues wit audio / DMA and other things where we were suffering from patches we missed due to the lack of time for rebasing. Do you know about any USB related fixes lately done, which we might have to backport?

Hi Christian,

I guess at first you can try to boot the SK with the Processor SDK Linux image which corresponds to the kernel you use on your custom board, then load the g_mass_storage gadget in the same way that you do on your custom board, then do the file transfer.

In the pas several years, all the USB related issues that our customer reported are not USB performance related that as this one you reported. So I am not sure which kernel patch to back port from the latest kernel, without knowing the root cause of the issue.

Hi Lin Lui,

I did not see any message regarding the USB in dmesg nor any on the console. 

Hi all,

a bit more details from my side:

Conditions

• Happens on many Windows 11 and Linux hosts

• Happens only when connected without an USB hub

• Does work on mac books and android devices even without hub

• Happens on transferring many (tested with 300 - 800) files, never seen with one big file

• Transfer usually starts fast and stops then at some point

Analyzes

Wireshark USB log shows a long time from the read request until the response is coming in:

Watching the USB state within the device shown that those stalls are aligned with state changes on the USB port. On windows the stall time is about 20sec always as seen on the wireshark log above, while on Linox this is 30sec. 

# Monitoring /sys/class/udc/31000000.usb (interval=0.2s, mode=changes)
# columns: TIMESTAMP  state  current_speed
2026-07-18 06:20:16  state=configured  current_speed=high-speed
2026-07-18 06:20:54  state=default  current_speed=high-speed
2026-07-18 06:20:55  state=configured  current_speed=high-speed

So either send out packages from the device do not reach the host, or they are not even send because the request did not get received.

It is very likely that the host ‘resets’ the channel, which is depending on the hostOS done in different timeouts.

Here is a more detailed investigation report created by claude having access to the serial consoleMIOT-USB Data transfer stall investigation report-280726-101959.pdf

Hi Heinz,

Thanks for the details.

A couple of comments related to the PDF report.

Regarding section 4.2, to rule out this is not USB runtime PM related, please change the runtime PM setting as:

#  echo on > /sys/devices/platform/bus@f0000/f900000.dwc3-usb/power/control

Section 4.3 mentions your project has a gadget management daemon. Please ensure the usb gadget backend LUN volume is not mounted simultaneously on AM62x Linux side and the USB host side. The kernel g_mass_storage gadget is not designed for such use case. Other than data corruption, I am not sure if it has any other implications.

I quickly looked at the current kernel v6.6. and v6.18, the kernel driver dwc3 directory has about 200 new patches. Can you please test with the latest v6.18 kernel to see if the issue also happens?

Hi Bin Liu  ,

I tried adding these properties to DTS usb node to disable low power mode and it's working now. 

&usb0 {
    dr_mode = "peripheral";
 	#address-cells = <1>;
 	#size-cells = <0>;
	maximum-speed = "high-speed";
+	snps,usb2-gadget-lpm-disable;
+	snps,dis_enblslpm_quirk;
+	snps,dis_u2_susphy_quirk;
 	usb-role-switch;
 	status = "okay";
 };

this shows that it could be the issue of usb link entering low power state between short idle periods? What do you think about this, it could be the solution for our issue?

Hi Bin Liu 

keeping only this patch changes solves our issue. Thankyou.

We can close this ticket.

Thanks for the update. This is closed.