PROCESSOR-SDK-AM335X: USB CDC read timeouts

Hi Durga Prasad,

Will it possible to hook a USB Analyser, instead of logic analyser ? Or you can enable USBMON in linux : https://www.kernel.org/doc/Documentation/usb/usbmon.txt

For USB MON make sure the following kernel config is enabled : CONFIG_USB_MON

You can also refer to the debugging guide here to enable further debugging : https://training.ti.com/sites/default/files/docs/USB-M7-Debug-USB-in-Linux.pdf

Hi,

Which version of the Processor SDK linux do you use?

Please provide the output of the command 'lsusb -v <vid:pid>' where <vid:pid> is for the MCU usb device.

Do you enable MUSB CPPI41 DMA on AM335x? If so, try to disable it in kernel menuconfig to see if changes the behavior.

Hi Dwarakesh,

I have captured the USB logs using USBMon. Attached the logs for the same. Please let me know Your findings.

MCU is configured in bulk transfer mode.

In lower most layer of USB packet transfer what is the expected delay between two 64Bytes packet?

Thanks & Regards

DurgaPrasad.

USB_Mon_Logs.zip

HI Bin Liu,

Please find the USB demesg info.

usb 1-1: new full-speed USB device number 4 using musb-hdrc
usb 1-1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: STM32 Virtual ComPort in FS Mode
usb 1-1: Manufacturer: STMicroelectronics
usb 1-1: SerialNumber: 356137543238
cdc_acm 1-1:1.0: ttyACM0: USB ACM device

Hi Durga Prasad,

just out of curiosity, if you have two embedded devices, the AM335x and another MCU, why don't you just use a serial port to exchange the data? Seems less overhead/complicated, especially on the MCU side (might even be able to pick a smaller, cheaper MCU, since USB stacks tend to be rather heavy on MCUs).

Regards, Andreas

Hi Durga Prasad,

Are the files captured at the time of failure ? Will it be possible to communicate to a Linux PC and get the same sensor data from MCU ? That way you can narrow down on issue with MCU or AM335x

Hi Andreas,

this was our first approach. But the required data throughput could not be met with UART. The MCU anyhow has a USB stack on board and the HW requirements are anyhow high to this controller bacause of the measurements we do with it.

Best regards,

Christian

Hi,

I have one more doubt regarding the configuration of device tree.

In device tree I have configured usb1 as host and did not specify maximum-speed parameter, where as my device side I have configured in Full Speed mode.

&usb1 {

status = "okay";

dr_mode = "host";

};

Questions:

1. Is it mandatory that maximum-speed has to set to full speed  as mentioned below?

&usb1 {

status = "okay";

dr_mode = "host";

maximum-speed = “full-speed”;

};

2. As per the doc the default value of maximum-speed is set to High Speed. Is this correct? and mandatory to specify maximum-speed parameter to full-speed in case device is configured in full speed mode?

https://training.ti.com/sites/default/files/docs/USB-M2-MUSB-Kernel-Config_0.pdf

3.No need  to set maximum-speed, Host will detect and take care internally the speed configuration?

Thanks & Regards

Durga Prasad.

Hi

Bin Liu

I have disabled the MUSB CPPI41 DMA in configs and device tree and tried. But USB RNDIS is Failing, unable to connect to device in this scenario. Where as I need USB RNDIS as well.

Device Tree Disable:

&usb1 {

status = "okay";

dr_mode = "host";

};

/*&cppi41dma {

status = "okay";

};*/

Config disable:

# CONFIG_USB_TI_CPPI41_DMA is not set

Thanks & Regards

Durga Prasad

Hi Durga,

USB 2.0 is backward compatible to full speed and the speed mentioned is maximum-speed and not tied to that speed. Detection of USB full speed or high speed is on the hardware(and the USB Controller) and it should not make any difference if it is configured as high-speed or full-speed in the dts. The host controller should be able to identify the speed.

Durga,

setting maximum-speed = “full-speed” only makes sense when you attach a usb high-speed device to musb host port but want the connection to be full-speed only for whatever reason.

I never saw a case in which USB RNDIS (or any USB device) fails when CPPI41 DMA is disabled. Sounds like something fundamentally wrong. Please share the failure log. What kernel version do you use?

Hi BinLiu,

Thanks for quick reply.

I am using Kernel version  4.19.67. We are not using TI SDK. we are following Debian buster Linux Package.

I directly set CONFIG_USB_TI_CPPI41_DMA=n in .config file earlier. Now I disabled through menu config, earlier I forgot to enable MUSB_PIO_ONLY. Now RNDIS is working.

.config changes:

##
## file: drivers/usb/musb/Kconfig
##
CONFIG_USB_MUSB_HDRC=y
## choice: MUSB Mode Selection
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_GADGET is not set
CONFIG_USB_MUSB_DUAL_ROLE=y
## end choice
# CONFIG_USB_MUSB_SUNXI is not set
# CONFIG_USB_MUSB_TUSB6010 is not set
# CONFIG_USB_MUSB_OMAP2PLUS is not set
# CONFIG_USB_MUSB_AM35X is not set
CONFIG_USB_MUSB_DSPS=y
CONFIG_MUSB_PIO_ONLY=y
# CONFIG_USB_INVENTRA_DMA is not set
# CONFIG_USB_TI_CPPI41_DMA is not set
# CONFIG_USB_TUSB_OMAP_DMA is not set

In my requirement I have other USB usecases usb0 (perpheral), usb1(Host) and USB (RNDIS) . If I disable the DMA in configs it will affect the through put of other USB's. I want to enable the DMA in configs and try to control the configuration from device tree.

Is there a way or method to enable DMA as default in .configs and disable DMA for usb1 alone in device tree? Please find my device tree configuration files related to usbs attached below.

am335x-Beaglebone.dts: stripped down version of main dts with usb changes alone.

am33xx.dtsi: include file with most of the configuration from TI

Can I do below changes like commenting out DMA part in am3xx.dtsi for disabling DMA alone for usb1 is that correct? or Need to add some parameter in am335x-Beaglebone.dts it will internally take care of disabling DMA for usb1 alone.

am33xx.dtsi:

usb1: usb@47401800 {
                compatible = "ti,musb-am33xx";
                status = "disabled";
                reg = <0x47401c00 0x400
                    0x47401800 0x200>;
                reg-names = "mc", "control";
                interrupts = <19>;
                interrupt-names = "mc";
                dr_mode = "otg";
                mentor,multipoint = <1>;
                mentor,num-eps = <16>;
                mentor,ram-bits = <12>;
                mentor,power = <500>;
                phys = <&usb1_phy>;

               //comment out to disable DMA for usb1

                /*dmas = <&cppi41dma 15 0 &cppi41dma 16 0
                    &cppi41dma 17 0 &cppi41dma 18 0
                    &cppi41dma 19 0 &cppi41dma 20 0
                    &cppi41dma 21 0 &cppi41dma 22 0
                    &cppi41dma 23 0 &cppi41dma 24 0
                    &cppi41dma 25 0 &cppi41dma 26 0
                    &cppi41dma 27 0 &cppi41dma 28 0
                    &cppi41dma 29 0 &cppi41dma 15 1
                    &cppi41dma 16 1 &cppi41dma 17 1
                    &cppi41dma 18 1 &cppi41dma 19 1
                    &cppi41dma 20 1 &cppi41dma 21 1
                    &cppi41dma 22 1 &cppi41dma 23 1
                    &cppi41dma 24 1 &cppi41dma 25 1
                    &cppi41dma 26 1 &cppi41dma 27 1
                    &cppi41dma 28 1 &cppi41dma 29 1>;
                dma-names =
                    "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
                    "rx8", "rx9", "rx10", "rx11", "rx12", "rx13",
                    "rx14", "rx15",
                    "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7",
                    "tx8", "tx9", "tx10", "tx11", "tx12", "tx13",
                    "tx14", "tx15";*/
            };

Thanks & Regards,

Durga Prasad.

5584.DeviceTreeFiles.zip

Hi Durga,

Durga Prasad Reddy B said:

In my requirement I have other USB usecases usb0 (perpheral), usb1(Host) and USB (RNDIS) .

Originally you mentioned you have timeout issue with the USB CDC device (by the way which CDC protocol is it? CDC ACM or CDC Ethernet?). Now you said RNDIS only works if CPPI41 DMA is disabled. Are you having two separate issues? Is this RNDIS protocol for MUSB host port (usb1) or device port (usb0)?

Durga Prasad Reddy B said:

Is there a way or method to enable DMA as default in .configs and disable DMA for usb1 alone in device tree?

Unfortunately the MUSB drivers do not support it. Its DMA can only be controlled by the kernel config option.

Hi Bin Liu,

Sorry for confusion.

In total we have two usbs, usb0 and usb1.

usb0(peripheral): (Multi function Composite Gadget i.e same usb0 is used as CDC ACM / Mass Storage / RNDIS to communicate with WINDOWS PC. Loading of drivers based on detection is taken care and  working as expected)

usb1 (host): CDC ACM i.e which will act like USB to Serial, which will communicate with device sensor node in FS mode. Where as timeout scenario is being observed for this node.If I disable DMA timeout scenario is not observed. Still regression testing under progress.

Now the question is since both places we are using USB CDC, usb0 is configured in peripheral default in HS mode and other usb1 in host and device communicating with host is configured in FS mode . If I disable the DMA it will affect both usb0 and usb1 CDC ACM.

1. Whether it will affect the throughput of usb0?

2. Is there a way so that I can deactivate DMA only for usb1 from device tree?

3. By default I will enable DMA and disable only in device tree. Can I do below change in device tree to disable DMA for usb1 alone?

am33xx.dtsi file changes:

usb1: usb@47401800 {
                compatible = "ti,musb-am33xx";
                status = "disabled";
                reg = <0x47401c00 0x400
                    0x47401800 0x200>;
                reg-names = "mc", "control";
                interrupts = <19>;
                interrupt-names = "mc";
                dr_mode = "otg";
                mentor,multipoint = <1>;
                mentor,num-eps = <16>;
                mentor,ram-bits = <12>;
                mentor,power = <500>;
                phys = <&usb1_phy>;

/*comment to disable DMA for usb1*/

               /* dmas = <&cppi41dma 15 0 &cppi41dma 16 0
                    &cppi41dma 17 0 &cppi41dma 18 0
                    &cppi41dma 19 0 &cppi41dma 20 0
                    &cppi41dma 21 0 &cppi41dma 22 0
                    &cppi41dma 23 0 &cppi41dma 24 0
                    &cppi41dma 25 0 &cppi41dma 26 0
                    &cppi41dma 27 0 &cppi41dma 28 0
                    &cppi41dma 29 0 &cppi41dma 15 1
                    &cppi41dma 16 1 &cppi41dma 17 1
                    &cppi41dma 18 1 &cppi41dma 19 1
                    &cppi41dma 20 1 &cppi41dma 21 1
                    &cppi41dma 22 1 &cppi41dma 23 1
                    &cppi41dma 24 1 &cppi41dma 25 1
                    &cppi41dma 26 1 &cppi41dma 27 1
                    &cppi41dma 28 1 &cppi41dma 29 1>;
                dma-names =
                    "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
                    "rx8", "rx9", "rx10", "rx11", "rx12", "rx13",
                    "rx14", "rx15",
                    "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7",
                    "tx8", "tx9", "tx10", "tx11", "tx12", "tx13",
                    "tx14", "tx15";

                */
            };

Thanks & Regards,

Durga Prasad.

Hi Durga,

Thanks for the clarification.

Please try the following kernel patch with CPPI41 DMA enabled to see if it fixes the issues. What the patch does is to not use DMA for the transfers which size is no more than 8 bytes.

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index c687b9b9808c..fd72f56b6ab4 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -709,12 +709,19 @@ static void musb_ep_program(struct musb *musb, u8 epnum,

        musb_ep_select(mbase, epnum);

-       if (is_out && !len) {
+       if (len <= 8) {
                use_dma = 0;
-               csr = musb_readw(epio, MUSB_TXCSR);
-               csr &= ~MUSB_TXCSR_DMAENAB;
-               musb_writew(epio, MUSB_TXCSR, csr);
-               hw_ep->tx_channel = NULL;
+               if (is_out) {
+                       csr = musb_readw(epio, MUSB_TXCSR);
+                       csr &= ~MUSB_TXCSR_DMAENAB;
+                       musb_writew(epio, MUSB_TXCSR, csr);
+                       hw_ep->tx_channel = NULL;
+               } else {
+                       csr = musb_readw(epio, MUSB_RXCSR);
+                       csr &= ~MUSB_RXCSR_DMAENAB;
+                       musb_writew(epio, MUSB_RXCSR, csr);
+                       hw_ep->rx_channel = NULL;
+               }
        }

        /* candidate for DMA? */

Durga Prasad Reddy B said:

1. Whether it will affect the throughput of usb0?

If the patch above works, it shouldn't affect throughput, because using DMA to transfer small packets is not efficient anyway.

Durga Prasad Reddy B said:

2. Is there a way so that I can deactivate DMA only for usb1 from device tree?

No, the MUSB driver doesn't provide a DMA control interface in device tree.

Durga Prasad Reddy B said:

3. By default I will enable DMA and disable only in device tree. Can I do below change in device tree to disable DMA for usb1 alone?

No, the MUSB driver doesn't support it. If CPPI41 DMA is enabled in kernel config but dmas/dma-names are not provided in device tree, MUSB driver probe() will fail.

Hi Bin Liu,

I have more than 4K size sensor data approx 4236 Bytes to be transferred from device to host. In FS mode at lowest layer it can send max 64 Bytes. So Host will try 66 times and last 12 bytes remaining. i.e 66x64 + 12 = 4224+12 = 4236 Bytes.

In my scenario i.e data bytes are more than 4K, the above patch will still work or it is for data Bytes less than 8 Bytes scenario only?

Thanks & Regards

Durga Prasad.

Durga,

There are many different type of transactions in USB communication, so in your scenario even most of the RX data transactions have 64 bytes data, but there are other USB packets, for example, protocol handshake packets,which would be much shorter, so the patch still worth a test.

if the patch does solves the issue, please change the condition to (len <= 12) so that the last RX packet won't use DMA, to see if it solves the issue. If not, we would have a different debug plan.

Hi Bin Liu,

Option 1.) Disable DMA in the .config :

May effect the through put of other usbs. Cannot choose this option. But where as timeout issue is not observed with this change, tested for around 1 and half day.

Option 2.) Disable DMA from device tree for usb1 alone:

Did the changes and tested for around 1 and half day. No Timeout issue is observed.I did not see any driver probe failures in dmesg log as well.

$ sudo dmesg | grep "usb"
[    0.132899] usbcore: registered new interface driver usbfs
[    0.132979] usbcore: registered new interface driver hub
[    0.133126] usbcore: registered new device driver usb
[    1.358478] usbcore: registered new interface driver cdc_acm
[    1.374954] am335x-phy-driver 47401300.usb-phy: 47401300.usb-phy supply vcc not found, using dummy regulator
[    1.385578] am335x-phy-driver 47401300.usb-phy: Linked as a consumer to regulator.0
[    1.397408] am335x-phy-driver 47401b00.usb-phy: 47401b00.usb-phy supply vcc not found, using dummy regulator
[    1.408139] am335x-phy-driver 47401b00.usb-phy: Linked as a consumer to regulator.0
[    1.418693] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
[    1.424852] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 1
[    1.433002] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[    1.441757] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.449383] usb usb1: Product: MUSB HDRC host driver
[    1.454634] usb usb1: Manufacturer: Linux 4.19.0-6-armmp musb-hcd
[    1.461068] usb usb1: SerialNumber: musb-hdrc.1
[    2.039688] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[    2.192956] usb 1-1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[    2.201652] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.209202] usb 1-1: Product: STM32 Virtual ComPort in FS Mode
[    2.215367] usb 1-1: Manufacturer: STMicroelectronics
[    2.220701] usb 1-1: SerialNumber: 356137543238
[   17.332822] usb0: HOST MAC fa:7e:5e:42:6f:1a
[   17.361498] usb0: MAC 9a:23:43:b1:2a:2e
[   17.945322] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready

Option 3.) Applied the musb_host.c patch to disable DMA:

Able to observe the USB Timeouts with condition len <= 8, I cannot keep len <= 12 as well not sure the last packet will always be 12 bytes it may vary.

Thanks & Regards,

Durga Prasad.

Let's continue the discussion in the new thread e2e.ti.com/.../921512.