Linux/AM3354: AM3354 USB fail when Bulk transfer size is multiple of 512 bytes

Thomas Yang55737

Part Number: AM3354

Tool/software: Linux

Hi Expert,

In my customer scenario, AM3354 USB work as HOST, and the external USB client is a 4G module, from our study, when the application layer packet transfer size is larger than 512bytes, the USB controller driver divided the application packet by 512 to several small packet and feed it to USB transfer hardware to transfer, for example,1024bytes application transfer packet is divided as 512 bytes+512 bytes+0 and there are 3 transfer request in driver layer, and 1025 is divided as 512+512+1. In hardware level, the largest bulk transfer is 512bytes, so this is compatible with USB20 spec and AM335x USB controller spec.

In our test, we found in AM3354 side, if the receive packet is just multiple of 512bytes, for example 1024 bytes, 512+512+0, the last "0" packet receive transfer can not be finished successfully as Linux kernel last "0" URB request can not be respond in time, so the transfer will be hang there until time-out event occur,

If the receive packet is not multiple of 512 bytes, for example 1025bytes, 512+512+1, the last "1" packet transfer can be finished successfully and Linux kernel URB request can be respond in time.

we will update the Linux kernel version later.

Also we have already checked below e2e link:

http://e2e.ti.com/support/processors/f/791/t/359580?tisearch=e2equicksearch&keymatch=usb%20bulk,

But it looks like it just discussed about bulk data transfer size in USB20 spec not same as our case. Could you give some explain on this behavior and debug suggestion?

Thanks!

-Thomas

over 6 years ago

0 Bin Liu over 6 years ago

TI__Guru**** 167191 points

Hi Thomas,

In the failure RX case, have you checked the USB bus that the 0-byte packet was transmitted from the device side (the 4G modem)?

What is the kernel version?

0 Thomas Yang55737 over 6 years ago in reply to Bin Liu

TI__Expert 4966 points

Linux Kernel version is 3.2.0

I asked customer to test the bus transmit status for 0 bytes packet, if it can be tested, I will let you know the result.

Besides this, do you have any other suggestion?

0 Thomas Yang55737 over 6 years ago in reply to Thomas Yang55737

TI__Expert 4966 points

Hi Bin,
Customer tested the BUS and found the 0 packet has already been sent in the BUS

0 Bin Liu over 6 years ago in reply to Thomas Yang55737

TI__Guru**** 167191 points

Hi Thomas,

I think you know that kernel v3.2.0 is very old and no longer supported. But depending on what copy of the v3.2.0 kernel the customer has, there might be a bug in the kernel which causes the 0-byte packet is not handled properly.

Please ask the customer to check if their kernel already has the patch #6.2 mentioned in the wiki below, which fixes the RX 0-byte packet problem. I also recommend to verify if all the patch 6.1~6.7 are already applied.

processors.wiki.ti.com/.../Sitara_Linux_MUSB_Issues

0 Bin Liu over 6 years ago in reply to Bin Liu

TI__Guru**** 167191 points

Hi Thomas,

I haven't heard back from you, is the issue solved with the patch I mentioned above?

0 user5855234 over 6 years ago in reply to Bin Liu

Prodigy 40 points

HI:

When the patch was patched, there was a marked improvement in the test. But the actual customer test has not improved.

Before the patch:

root@ok335x:~# ping -s 484 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 484 data bytes
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss

After the patch:

root@ok335x:~# ping -s 484 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 484 data bytes
492 bytes from 8.8.8.8: seq=0 ttl=114 time=419.209 ms
492 bytes from 8.8.8.8: seq=1 ttl=114 time=291.908 ms
492 bytes from 8.8.8.8: seq=2 ttl=114 time=281.592 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 281.592/330.903/419.209 ms

0 Bin Liu over 6 years ago in reply to user5855234

TI__Guru**** 167191 points

Hi,

The log shows the patch solves the ping packet loss problem.

Do you mean the customer still have the same problem with the 4G module after applied the patch?
Have you checked if the customer has applied the patch correctly? You can compare (use linux diff command) the customer's patched kernel file with yours.
Have your customer applied the patch #6.1~#6.7 I mentioned above?

0 user5855234 over 6 years ago in reply to Bin Liu

Prodigy 40 points

HI，
By comparing the source code, my client has applied the patch mentioned above from 6.1 to 6.7。Is the above log phenomenon mentioned above a patch to solve such problems?

0 Bin Liu over 6 years ago in reply to user5855234

TI__Guru**** 167191 points

Well, I don't know, I don't know what caused the ping failure without checking the usb bus trace and kernel debug log.

If the mentioned patch 6.1-6.7 doesn't solve the customer's 4G module problem, it means the problem is not something I saw before, and I don't have a solution for the old v3.2 kernel, sorry.

0 Bin Liu over 6 years ago in reply to user5855234

TI__Guru**** 167191 points

Wait, have you checked if disabling the CPPI DMA solve the problem with the 4G module?

0 user5855234 over 6 years ago in reply to Bin Liu

Prodigy 40 points

How to disable CPPI DMA?

0 Bin Liu over 6 years ago in reply to user5855234

TI__Guru**** 167191 points

I don't have access to kernel source code at the moment to tell you the exact procedure, but you need to do kernel 'make menuconfig', then to go 'Device Drivers' --> 'USB Support', then scroll down to the Mentor USB section, you will see an option called something about PIO mode, enable this option.

0 Bin Liu over 6 years ago in reply to user5855234

TI__Guru**** 167191 points

In kernel menuconfig:

Device Drivers
    USB Support
        Inventra Highspeed Dual Role
            Disable DMA (always use PIO)

0 user5855234 over 6 years ago in reply to Bin Liu

Prodigy 40 points

Well, thank you very much. Let me have a try.

Processors

Processors forum

Linux/AM3354: AM3354 USB fail when Bulk transfer size is multiple of 512 bytes