ping to usb interface fails for large packets



Hello Sir,
am currently working on OMAP34XX series USB OTG controller. The USB OTG
controller is configured to operate in peripheral mode which is using
GADGET USB stack. Am lost debugging this issue. If any pointers /
suggestions are highly appreciated.

Problem description:
--------------------
ping AAA.BBB.CC.DD -t -l 20000 fails with failure message
"Request timed out"

Debug procedure currently used:
-------------------------------
1. Using Wireshark to monitor the USB interface for TX and RX
2. Using RAM logs to trace if any error scenario occurs.

Observations:
-------------
1. Using wireshark
a. ping AAA.BBB.CC.DD -t -l 10000 works fine.
on RX ( ping request )
packets are divided into 1 -> 2 -> 3-> 4 -> 5 ... packets of almost same
sizes upto the last packet are sent from Host -> Device.
on TX ( ping reply )
packets are divided into 1 -> 2 -> 3-> 4 -> 5 ... packets of almost same
sizes upto the last packet are sent from Device -> Host.

b. ping AAA.BBB.CC.DD -t -l 20000 and above fails.
on RX ( ping request )
packets are divided into 1 -> 2 -> 3-> 4 -> 5 ... packets of almost same
sizes upto the last packet are sent from Host -> Device.
on TX ( ping reply )
packets are divided into 1 -> 2 -> 3 packets of almost same sizes sent to
the host, accepts next ping request packets completely and then sends -> 4
-> 5 ... packets of previous previous ping reply are sent from Device ->
Host.


2. Using RAM logs
a. No error scenarios wrt DMA / stall wrt transactions.
b. In case of RX packets of size 1514 is divided into 0x200 + 0x200 + 0x1EA
are receieved via DMA
c. In case of TX packet of size 1514 is programmed via DMA channel and
triggered for the transaction.
d. Good case vs Bad case logs almost shows no differences.

I don't have a CATC Analyser. BTW A INTRODUCTION OF DELAY OF 4msec in
musb_g_giveback( )resolves the issue.
But this is not the right approach.

Am open to your suggestions / comments.

Please let me know if you need more info.

Regards,
Sandeep


---------------------------------------
Posted through http://www.EmbeddedRelated.com
.