USB Packet error in the new "B" version of AM3352BZCZD60

Hi Allen,

I will escalate this to our USB expert.

Allen,

Assuming you use TI SDK kernel, if so, what SDK version do you use?

Do you use DMA or PIO mode for MUSB? If you use DMA mode, do you see the error in PIO mode?

Does the packet error happen on RX or TX, or both? Do you have any log or protocol analyzer trace to show the error?

The two versions of the AM335x devices are on two different prototype boards or the same board?

hi Bin Lui,

please see answers to your questions below

Amswer to Q1

the kernel we use originates from the Arago GIT repository. We are based on commit ID 4be2ce1b85bcec765a05f30, with small patches to the MUSB driver to enable non RNDIS CDC (allow zero length Rx packet) and enable bulk split/combine (.mult_bulk_tx=1, .mult_bulk_rx=1).

Amswer to Q2

I believe we are using DMA mode. Is there a known issue with DMA between the two processor revisions?

Amswer to Q3 and Q4

The RevB processors are on a slightly redesigned board. Notably, there are changes to the processor's crystal oscillator layout. We will attempt to get some processors swapped between boards, but that will take a while.

The board connects the processor to a device (multiple USBSerial endpoints) via a hub.

There are two. possibly independent issues we can see.

1) is most likely related to the new board design (noisy or jittery clock). The Beagle (USB analyzer) traces show many orphaned transactions, repeated a few times, until they are acknowledged.

This shows up only when the processor is connected via the hub. Bypassing the hub, the issue goes away. Independently, connecting a known good host to the same hub is also OK. It looks like the combination of RevB processor, new board and hub is required to produce these errors.

2) Even on a configuration where the Beagle shows no orphaned packets, we have another error.

* The USB device (LTE modem) has USB-Serial endpoints which map into /dev/ttyUSBn in user space.

* We open one such endpoint in a serial terminal program and manually issue AT commands.

* As soon as an AT command has a response >512 bytes, there are no more responses after it has successfully finished. In our case, the response consists of 4x512 + 1x3nn byte packets on the bus.

* Watching the kernel's USB-mon messages, we can see that the (only) URB assigned to this Rx endpoint gets re-submitted after every Rx packet, including after the last one of the large transfer.

* However, the host controller is not issuing any more Rx polls for that endpoint. Other endpoints continue to be polled as normal, Tx is fine.

Somewhere between the kernel's USB core, the MUSB driver and the HC hardware, the Rx URB has been lost.

* Closing and re-opening the ttyUSB port cancels and resubmits that URB and operation resumes. This leads to reception of all the missing responses from the modem.

It looks very much as if the re-submitted URB can, under some unknown conditions, fail to be included in the HC's bulk schedule.

The large, multi-packet Rx transfer seems to be a reliable trigger for the issue, and so far the only one we found.

The exact same firmware image on a RevA processor is OK, but there seems to be code in the MUSB driver which changes behaviour depending on processor revision. That is, the executed code is not necessarily identical.

Allen Mekerdichian said:

enable bulk split/combine (.mult_bulk_tx=1, .mult_bulk_rx=1).

Why you want to enable this?

Allen Mekerdichian said:

Amswer to Q2

I believe we are using DMA mode. Is there a known issue with DMA between the two processor revisions?

Yes. Due to the issue in Errata Advisory 1.0.13, the DMA driver uses a sw workaround for older silicons (no B). If you are interested, the workaround is using DMA transparent mode vs. generic rndis mode. The TRM has details about those modes.

Allen Mekerdichian said:

1) is most likely related to the new board design (noisy or jittery clock).

To determine if this is a hw issue, please debug it with USB DMA disabled. That will minimize the sw impact.

Allen Mekerdichian said:

2) Even on a configuration where the Beagle shows no orphaned packets, we have another error.

To debug the 2nd issue, please change your kernel as below, which enables the transparent mode workaround, this is the same as for no-B revision. Please ensure DMA is enabled, this is different debug approach from issue #1.

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index fef2b50..a3f8da3 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -116,7 +116,6 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
                        board_data->txfifo_intr_enable = 0;
 
                if (cpu_is_am33xx() && omap_rev() >= AM335X_REV_ES2_0) {
-                       board_data->grndis_for_host_rx = 1;
                        board_data->babble_ctrl = 1;
                }
        } else {