• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 1390 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

Linux/DRA72: Carlife conneting failure by accident

Linux/DRA72: USB EAP write time out

Wesley
Prodigy 250 points
Part Number: DRA72


Tool/software: Linux

the carlife already connected success，but still occur EAP write timeout when use the IF 3，then I use USB logic analyzer to capture data，result indicate the last data do not sent out.

attachment is a related log, the cat /sys/kernel/debug/tracing/trace since line 26691.

please help me !

Thank you！

Qin Xin.

Desay sv.in nak.txt

  • 0
    TI__Mastermind 49253 points

    Hi Qin Xin,

    Can you point me to the line number in the trace file that point to the EAP write timeout.. what is the data packet content that was not sent out?.

    Also can you share the corresponding logic analyzer file you are referring above? Please denote the exact location in the logic analyser log where you see the data is missing.

    -Praveen

  • 0 in reply to Praveen Rao
    Prodigy 250 points

    Dear Praveen,

    data can't sent out since line 38928 :svp.svc.link-1081  [000] d..3   403.618444: dwc3_ep_queue: ep4in: req ebf12780 length 0/8 ==> -115,

    and the logic analyzer file have already upload to attachment,data can't sent out since index 21225 in the analyzer file.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/innak.7z

    thank you.

    Qin Xin.

    Desay SV.

  • 0 in reply to Wesley
    TI__Mastermind 49253 points

    Thank you Qin Xin for the details,

    The driver thinks that it has sent out the 8 bytes that it is supposed to send as we see the acknowledgement back and it is even being printed.

    Note that the return value -115 denotes EINPROGRESS and is not an error condition.

    For the request:

    line 38928 :svp.svc.link-1081  [000] d..3   403.618444: dwc3_ep_queue: ep4in: req ebf12780 length 0/8 ==> -115

    The response of the request transfer:

    line 38929 :3213.76>     svp.svc.link-1081  [000] d..3   403.618454: dwc3_gadget: ep4in: req ebf12780 dma aa7fc000 length 8 last

    line 38930 : 3213.76>     svp.svc.link-1081  [000] d..3   403.618462: dwc3_prepare_trb: ep4in: trb f2b17000 bph 00000000 bpl aa7fc000 size 00000008 ctrl 00000813

    line 38931 : 3213.76>     svp.svc.link-1081  [000] d..3   403.618465: dwc3_gadget_ep_cmd: ep4in: cmd 'Start Transfer' [6] params 00000000 bbc7a000 00000000

    line 38932 : 3213.76>     svp.svc.link-1081  [000] d..3   403.618471: dwc3_gadget: Command Complete --> 0

    But I do see that before this request being send out, there was an ep3out transaction coming from host that never got completed.  See :

    line n38937: 3213.76>     svp.svc.link-1080  [000] d..3   403.333524: dwc3_ep_queue: ep3out: req ebf12680 length 0/8192 ==> -115

    Do we know why this is not being handled?  I see the same in the logic analyze as well. so suspect  the the actual issue started there.

    How often this issue is happening? Who is handling the ep3out and ep4in data? Are we sure the gadget that handle them is not the issue here?

    -Praveen

  • 0 in reply to Praveen Rao
    TI__Mastermind 49253 points
    Hi Qin Xin,

    I haven't heard back from you, I'm assuming you were able to resolve your issue.
    If not, just post a reply below (or create a new thread if the thread has locked due to time-out).

    -Praveen