ping to usb interface fails for large packets
in [Embedded]
|
From: Sandeeptssmg on 5 Mar 2010 04:35 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
From: Sandeeptssmg on 8 Mar 2010 03:21 >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 > Hi, any pointers / suggestions regarding above issue ? Please let me know. Regards, Sandeep --------------------------------------- Posted through http://www.EmbeddedRelated.com
|
Pages: 1 Prev: Timer for every frame ? Next: ADS1255 (24-bit ADC) Initialisation command sequence |