• State Resolved
  • Locked Locked
  • Replies 78 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 15397 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Another CPPI USB DMA issue

Eilon Eyal74533
Intellectual 390 points

Hello,

I am using this post to reopen a previously opened post, which I mistakenly thought solved the issue. we still see the issue of DMA hang after applying the 5 patchs from TI (http://processors.wiki.ti.com/index.php/Sitara_Linux_MUSB_Issues#AMSDK_06.00.00.00

I am working a AM3356 based product which is connected to a USB modem through USB. The usb modem exports a composite usb interface composed from 2 CDC-ECM and 1 CDC-ACM. the Sitara is the USB host and the modem is the USB device.

we are using .SDK-06.00.00.00 with psp04.06.00.11 . the kernel is linux-3.2.0-psp04.06.00.11

during data transfers (around 2KB/S) we suddenly see the USB on the Sitara side stops and there is no way to recover except reboot. configuring the USB to use PIO instead of DMA seems to solve the issue, but we would like to use DMA since we expect much higher throughput (we hope to get ~60 Mbit/S)

while normal operation the regdeump shows:

USB (M)HDRC Register Du
FAddr : 00
Power : f0
Frame : 06df
Index : 0f
Testmode : 00
TxMaxPp : 0000
TxCSRp : 0000
RxMaxPp : 0000
RxCSR : 0000
RxCount : 0000
ConfigData : 33
DevCtl : 5d
MISC : 44
TxFIFOsz : 07
RxFIFOsz : 07
TxFIFOadd : 0780
RxFIFOadd : 0780
VControl : 00000000
HWVers : 0800
EPInfo : ff
RAMInfo : 0d
LinkInfo : 5c
VPLen : 3c
HS_EOF1 : 80
FS_EOF1 : 77
LS_EOF1 : 72
SOFT_RST : 00
DMA_CNTLch0 : 0000
DMA_ADDRch0 : 00000000
DMA_COUNTch0: 00000000
DMA_CNTLch1 : 0000
DMA_ADDRch1 : 00000000
DMA_COUNTch1: 00000000
DMA_CNTLch2 : 0000
DMA_ADDRch2 : 00000000
DMA_COUNTch2: 00000000
DMA_CNTLch3 : 0000
DMA_ADDRch3 : 00000000
DMA_COUNTch3: 00000000
DMA_CNTLch4 : 0000
DMA_ADDRch4 : 00000000
DMA_COUNTch4: 00000000
DMA_CNTLch5 : 0000
DMA_ADDRch5 : 00000000
DMA_COUNTch5: 00000000
DMA_CNTLch6 : 0000
DMA_ADDRch6 : 00000000
DMA_COUNTch6: 00000000
DMA_CNTLch7 : 0000
DMA_ADDRch7 : 00000000
DMA_COUNTch7: 00000000
#

and while the issues appears we see:

# cat regdump 
MUSB (M)HDRC Register Dump 
FAddr : 00 
Power : e0 
Frame : 051d 
Index : 0f 
Testmode : 00 
TxMaxPp : 0000 
TxCSRp : 0000 
RxMaxPp : 0000 
RxCSR : 0000 
RxCount : 0000 
ConfigData : 33 
DevCtl : 19 
MISC : 44 
TxFIFOsz : 07 
RxFIFOsz : 07 
TxFIFOadd : 0780 
RxFIFOadd : 0780 
VControl : 00000000 
HWVers : 0800 
EPInfo : ff 
RAMInfo : 0d 
LinkInfo : 5c 
VPLen : 3c 
HS_EOF1 : 80 
FS_EOF1 : 77 
LS_EOF1 : 72 
SOFT_RST : 00 
DMA_CNTLch0 : 0000 
DMA_ADDRch0 : 00000000 
DMA_COUNTch0: 00000000 
DMA_CNTLch1 : 0000 
DMA_ADDRch1 : 00000000 
DMA_COUNTch1: 00000000 
DMA_CNTLch2 : 0000 
DMA_ADDRch2 : 00000000 
DMA_COUNTch2: 00000000 
DMA_CNTLch3 : 0000 
DMA_ADDRch3 : 00000000 
DMA_COUNTch3: 00000000 
DMA_CNTLch4 : 0000 
DMA_ADDRch4 : 00000000 
DMA_COUNTch4: 00000000 
DMA_CNTLch5 : 0000 
DMA_ADDRch5 : 00000000 
DMA_COUNTch5: 00000000 
DMA_CNTLch6 : 0000 
DMA_ADDRch6 : 00000000 
DMA_COUNTch6: 00000000 
DMA_CNTLch7 : 0000 
DMA_ADDRch7 : 00000000 
DMA_COUNTch7: 00000000

could you please advise

  • 0
    TI__Guru**** 393215 points

    Forwarding this to the USB experts.

  • 0
    TI__Guru**** 153651 points
    Eilon,

    The regdump shows the modem has been disconnected. Does the serial console has any message when the problem happens?

    Can you please kindly provide the link to the previous discussion?

    Please try to collect the following information for investigation.

    - 'cat /proc/driver/musb_hdrc.1' after the issue happened;

    - Enable kernel DYNAMIC_DEBUG and enable dev_dbg logs in function ti81xx_interrupt(). Bascically, I'd like to see the logs of the following debug to check interrupt events right before the issue happens.

    1081 dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr);
  • 0 in reply to Bin Liu
    Intellectual 390 points
    Hi,
    it took me sometime to reproduce the issue, attached are a new new dump files which represents the issue better:

    ## Before the issue happens ###
    ----- file : /sys/kernel/debug/musb-hdrc.0/regdump
    MUSB (M)HDRC Register Dump
    FAddr : 02
    Power : f0
    Frame : 009b
    Index : 00
    Testmode : 00
    TxMaxPp : 0000
    TxCSRp : 0000
    RxMaxPp : 0000
    RxCSR : 0000
    RxCount : 0000
    ConfigData : de
    DevCtl : 99
    MISC : 44
    TxFIFOsz : 00
    RxFIFOsz : 00
    TxFIFOadd : 0000
    RxFIFOadd : 0000
    VControl : 00000000
    HWVers : 0800
    EPInfo : ff
    RAMInfo : 0d
    LinkInfo : 5c
    VPLen : 3c
    HS_EOF1 : 80
    FS_EOF1 : 77
    LS_EOF1 : 72
    SOFT_RST : 00
    DMA_CNTLch0 : 0000
    DMA_ADDRch0 : 00000000
    DMA_COUNTch0: 00000000
    DMA_CNTLch1 : 0000
    DMA_ADDRch1 : 00000000
    DMA_COUNTch1: 00000000
    DMA_CNTLch2 : 0000
    DMA_ADDRch2 : 00000000
    DMA_COUNTch2: 00000000
    DMA_CNTLch3 : 0000
    DMA_ADDRch3 : 00000000
    DMA_COUNTch3: 00000000
    DMA_CNTLch4 : 0000
    DMA_ADDRch4 : 00000000
    DMA_COUNTch4: 00000000
    DMA_CNTLch5 : 0000
    DMA_ADDRch5 : 00000000
    DMA_COUNTch5: 00000000
    DMA_CNTLch6 : 0000
    DMA_ADDRch6 : 00000000
    DMA_COUNTch6: 00000000
    DMA_CNTLch7 : 0000
    DMA_ADDRch7 : 00000000
    DMA_COUNTch7: 00000000

    ----- file : /proc/driver/musb_hdrc.0
    Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99)
    OTG state: b_peripheral; active
    Options: ?dma?, otg (peripheral+host), [eps=16]
    Peripheral address: 00
    Root port status: 00000100
    CPPI: txcr=0 txsrc=0 txena=0; rxcr=0 rxsrc=280de80 rxena=0
    Gadget driver: g_cdc

    ep0 (hw0): 1buf, csr 0000 maxp 0000
    (queue empty)

    ep1in (hw1): 1buf dma, csr 2403 maxp 0200
    TX DMA0: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf492190, -820993808/-814996032
    req cf4921d0, -820993808/-815746112
    req cf492210, -820993808/-815778112
    req cf492250, -820993808/-815744192
    req cf492290, -820993808/-815743424
    req cf4922d0, -820993808/-815778496
    req cf492310, -820993808/-814995840
    req cf492350, -820993808/-815745152
    req cf492390, -820993808/-815744960
    req cf4923d0, -820993808/-815880576

    ep1out (hw1): 1buf dma, csr 2000 maxp 0200
    RX DMA0: 2 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf50bdd0, -820993808/-821723648
    req cf50be10, -820993808/-821723840
    req cf50be50, -820993808/-821724224
    req cf50be90, -820993808/-821724608
    req cf50bed0, -820993808/-821724800
    req cf50bf10, -820993808/-821726720
    req cf50bf50, -820993808/-821724032
    req cf50bf90, -820993808/-821725376
    req cf50bfd0, -820993808/-821726528
    req cf492150, -820993808/-821724416

    ep2in (hw2): 1buf dma, csr 2403 maxp 0010
    TX DMA1: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf492dd0, -820993808/-819242560

    ep2out (hw2): 1buf dma, csr 2000 maxp 0200
    RX DMA1: 268566788 left,00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf50b8d0, -820993808/-814996800
    req cf50b950, -820993808/-815776384
    req cf50b990, -820993808/-815882112
    req cf50b9d0, -820993808/-815776960
    req cf50ba10, -820993808/-815777152
    req cf50ba50, -820993808/-815768832
    req cf50ba90, -820993808/-815291072
    req cf50bad0, -820993808/-815290688
    req cf50bb10, -820993808/-815290112
    req cf50b910, -820993808/-815744384

    ep3in (hw3): 1buf dma, csr 2404 maxp 0200
    TX DMA2: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    ep3out (hw3): 1buf dma, csr 2000 maxp 0200
    RX DMA2: 256 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf50b590, -820993808/-821723456
    req cf50b5d0, -820993808/-821725568
    req cf50b610, -820993808/-821725760
    req cf50b3d0, -820993808/-821725952
    req cf50b410, -820993808/-821726144
    req cf50b450, -820993808/-821726912
    req cf50b490, -820993808/-821727104
    req cf50b4d0, -820993808/-821726336
    req cf50b510, -820993808/-815745920
    req cf50b550, -820993808/-821724992

    ep4in (hw4): 1buf dma, csr 2404 maxp 0010
    TX DMA3: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    ep4out (hw4): 1buf dma, csr 2000 maxp 0200
    RX DMA3: 0 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf5ce690, -820993808/0
    req cf5ce6d0, -820993808/0
    req cf5ce710, -820993808/0
    req cf5ce750, -820993808/0
    req cf5ce790, -82cat: read error: Invalid argument



    ##### AFTER the issue happens
    file--- /sys/kernel/debug/musb-hdrc.0/regdump
    MUSB (M)HDRC Register Dump
    FAddr : 02
    Power : f0
    Frame : 0046
    Index : 00
    Testmode : 00
    TxMaxPp : 0000
    TxCSRp : 0000
    RxMaxPp : 0000
    RxCSR : 0000
    RxCount : 0000
    ConfigData : de
    DevCtl : 99
    MISC : 44
    TxFIFOsz : 00
    RxFIFOsz : 00
    TxFIFOadd : 0000
    RxFIFOadd : 0000
    VControl : 00000000
    HWVers : 0800
    EPInfo : ff
    RAMInfo : 0d
    LinkInfo : 5c
    VPLen : 3c
    HS_EOF1 : 80
    FS_EOF1 : 77
    LS_EOF1 : 72
    SOFT_RST : 00
    DMA_CNTLch0 : 0000
    DMA_ADDRch0 : 00000000
    DMA_COUNTch0: 00000000
    DMA_CNTLch1 : 0000
    DMA_ADDRch1 : 00000000
    DMA_COUNTch1: 00000000
    DMA_CNTLch2 : 0000
    DMA_ADDRch2 : 00000000
    DMA_COUNTch2: 00000000
    DMA_CNTLch3 : 0000
    DMA_ADDRch3 : 00000000
    DMA_COUNTch3: 00000000
    DMA_CNTLch4 : 0000
    DMA_ADDRch4 : 00000000
    DMA_COUNTch4: 00000000
    DMA_CNTLch5 : 0000
    DMA_ADDRch5 : 00000000
    DMA_COUNTch5: 00000000
    DMA_CNTLch6 : 0000
    DMA_ADDRch6 : 00000000
    DMA_COUNTch6: 00000000
    DMA_CNTLch7 : 0000
    DMA_ADDRch7 : 00000000
    DMA_COUNTch7: 00000000


    file --- /proc/driver/musb_hdrc.0
    Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99)
    OTG state: b_peripheral; active
    Options: ?dma?, otg (peripheral+host), [eps=16]
    Peripheral address: 00
    Root port status: 00000100
    CPPI: txcr=0 txsrc=0 txena=0; rxcr=0 rxsrc=280de80 rxena=0
    Gadget driver: g_cdc

    ep0 (hw0): 1buf, csr 0000 maxp 0000
    (queue empty)

    ep1in (hw1): 1buf dma, csr 2404 maxp 0200
    TX DMA0: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    ep1out (hw1): 1buf dma, csr 2000 maxp 0200
    RX DMA0: 2 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf515f50, -821002000/-815131520
    req cf515f90, -821002000/-815130176
    req cf515fd0, -821002000/-821724032
    req cf491150, -821002000/-815081856
    req cf515dd0, -821002000/-815261248
    req cf515e10, -821002000/-815000320
    req cf515e50, -821002000/-815850112
    req cf515e90, -821002000/-815318272
    req cf515ed0, -821002000/-815851456
    req cf515f10, -821002000/-815852032

    ep2in (hw2): 1buf dma, csr 2404 maxp 0010
    TX DMA1: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    ep2out (hw2): 1buf dma, csr 2000 maxp 0200
    RX DMA1: 268566788 left,00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf515a50, -821002000/-820444480
    req cf515a90, -821002000/-815849728
    req cf515ad0, -821002000/-820442944
    req cf515b10, -821002000/-821726720
    req cf5158d0, -821002000/-815079744
    req cf515910, -821002000/-815132288
    req cf515950, -821002000/-815320192
    req cf515990, -821002000/-815317696
    req cf5159d0, -821002000/-815850304
    req cf515a10, -821002000/-815140480

    ep3in (hw3): 1buf dma, csr 2404 maxp 0200
    TX DMA2: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    ep3out (hw3): 1buf dma, csr 2000 maxp 0200
    RX DMA2: 256 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf515450, -821002000/-815262400
    req cf515490, -821002000/-820444672
    req cf5154d0, -821002000/-815853376
    req cf515510, -821002000/-820442176
    req cf515550, -821002000/-815260864
    req cf515590, -821002000/-814997824
    req cf5155d0, -821002000/-820445056
    req cf515610, -821002000/-820442752
    req cf5153d0, -821002000/-815130944
    req cf515410, -821002000/-815130560

    ep4in (hw4): 1buf dma, csr 2404 maxp 0010
    TX DMA3: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    ep4out (hw4): 1buf dma, csr 2000 maxp 0200
    RX DMA3: 0 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf5d9550, -821002000/0
    req cf5d9590, -821002000/0
    req cf5d95d0, -821002000/0
    req cf5d9610, -821002000/0
    req cf5d9650, -821002000/0
    req cf5d96d0, -821002000/0
    req cf5d9710, -821002000/0
    req cf5d9750, -821002000/0
    req cf5d9790, -821002000/0
    req cf5d97d0, -821002000/0
    req cf5d9810, -821002000/0
    req cf5d9850, -821002000/0
    req cf5d9890, -821002000/0
    req cf5d9910, -821002000/0
    req cf5d9950, -821002000/0
    req cf5d9990, -821002000/0

    ep5in (hw5): 1buf dma, csr 2404 maxp 0200
    TX DMA4: 0000000cat: read error: Invalid argument


    Thanks a lot for the help
  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,

    How often do you see the issue? How long does it take to happen?

    Eilon Eyal74533 said:
    ## Before the issue happens ###
    ----- file : /sys/kernel/debug/musb-hdrc.0/regdump
    ......
    DevCtl : 99

    ......
    ----- file : /proc/driver/musb_hdrc.0
    Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99)
    OTG state: b_peripheral; active
    ......

    ep3in (hw3): 1buf dma, csr 2404 maxp 0200
    ......
    ep4in (hw4): 1buf dma, csr 2404 maxp 0010

    Can you please double check the above log before the issue is the correct one? It shows the controller is already in an invalid state: the controller is in peripheral mode which has VBUS voltage >4.4V, and EP3IN and EP4IN have protocol errors which is that the host controller sent IN token 3 times but did not receive response from the device.

    Can you use a protocol analyzer to capture a bus trace? I'd like to see what was happening on the bus. If the trace is too big to attach. I can provide a link to upload.

    Is the USB0 port in host-only mode or OTG/DRD mode? Can you please share the Schematics?

    Did you capture the interrupt log I asked? That can give a clue there is any event causes the controller disconnect the device.

  • 0 in reply to Bin Liu
    Prodigy 60 points
    Hi,

    I cannot use protocol analyzer since the units are connected by hidden USB lines in the PCB.

    The USB0 is host only mode.

    I made a change at ti81xx.c - #define DEBUG before #include <linux/platform_device.h>


    if (musb->int_usb & MUSB_INTR_SOF) {
    musb->sof_cnt++;

    Add the line - dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr);



    The following is a log of musb_hdrc.1.

    cat /proc/driver/musb_hdrc.1
    Status: MHDRC, Mode=Host (Power=e0, DevCtl=19)
    OTG state: a_wait_bcon; inactive
    Options: ?dma?, otg (peripheral+host), [eps=16]
    Peripheral address: 00
    Root port status: 00000100
    CPPI: txcr=0 txsrc=0 txena=0; rxcr=0 rxsrc=280de80 rxena=0

    Regards,
    Shabtai
  • 0 in reply to Shabtai Haim
    TI__Guru**** 153651 points

    Shabtai Haim said:
    I made a change at ti81xx.c - #define DEBUG before #include <linux/platform_device.h>


    if (musb->int_usb & MUSB_INTR_SOF) {
    musb->sof_cnt++;

    Add the line - dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr);

    I am not sure what you were trying to do. But anyway please use the following instruction to generate the MUSB interrupt log.

    1. build the kernel with DYNAMIC_DEBUG enabled;

    2. after boot the board, run the following command.

    # mount -t debugfs none /sys/kernel/debug
    # echo 'func ti81xx_interrupt =p' > /sys/kernel/debug/dynamic_debug/control

    3. replicate the issue, then run 'dmesg > musb.log' command to dump the kernel log to a file, and provide the log.

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Hi,

    How do I send/upload the log file ? I would prefer it won't published in forum

    Regards,

    Shabtai

  • 0 in reply to Shabtai Haim
    TI__Guru**** 153651 points
    This log should not have any secret. But you can contact your local TI FAE if you don't want to post it here.
  • 0 in reply to Bin Liu
    Prodigy 60 points

    dma_issue.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    [ 33.599755] br0: port 1(usb0) entering forwarding state
    [ 33.679869] br1: port 1(usb1) entering forwarding state
    [ 33.685594] br1: port 2(eth1) entering forwarding state
    [ 34.519776] br0: port 2(eth0) entering forwarding state
    [ 54.343067]
    #
    #
    # dmesg
    , Rx 8
    [ 31.990207] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.990782] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.990873] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.991047] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.991146] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.991548] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.991633] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.991808] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.991936] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.992607] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.992931] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.993154] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.993264] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.993666] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.993728] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.993940] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.994013] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.994416] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.994477] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.994770] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.994844] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.995198] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.995289] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.995350] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.995381] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.995627] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.995734] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.996370] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.996431] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.996626] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.996698] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.997101] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.997161] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.997339] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.997412] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.998108] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 31.998170] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 31.998424] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.998553] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.999315] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.999397] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.999504] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 31.999576] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 31.999684] CPCAP get voltage
    [ 31.999793] CPCAP set voltage
    [ 31.999973] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 0, Rx 2
    [ 32.000064] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 2, Rx 0
    [ 32.000300] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 32.000424] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 32.000458] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 32.000565] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 32.000637] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 32.000754] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0
    [ 32.001095] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 32.001231] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 32.001360] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    [ 32.001481] musb-hdrc musb-hdrc.1: CPPI 4.1 IRQ: Tx 0, Rx 8
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Shabtai Haim
    TI__Mastermind 26195 points
    Bin is traveling and he will reply once he is back.
  • 0 in reply to Shabtai Haim
    TI__Guru**** 153651 points

    Shabtai Haim said:

    (Please visit the site to view this file)

    I asked to capture the log with

    # echo 'func ti81xx_interrupt =p' > /sys/kernel/debug/dynamic_debug/control

    Not

    # echo 'func cppi41dma_Interrupt =p' > /sys/kernel/debug/dynamic_debug/control

    The log you provided is not what I am looking for.

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Hi,

    I run the following commands:

    # mount -t debugfs none /sys/kernel/debug
    # echo 'func ti81xx_interrupt =p' > /sys/kernel/debug/dynamic_debug/control

    Regards,

    Shabtai

  • 0 in reply to Shabtai Haim
    TI__Guru**** 153651 points

    Then please double check if you have run the command correctly.

    The log you posted only has message "musb-hdrc musb-hdrc.x: CPPI 4.1 IRQ: Tx x, Rx x", this print statement is only in function cppi41dma_Interrupt().

    If you had enabled debug for function ti81xx_interrupt(), the log should have message: "musb-hdrc musb-hdrc.x: usbintr (x) epintr(x)" instead.

  • 0 in reply to Bin Liu
    Prodigy 60 points
    Hi,

    At file drivers/usb/musb/ti81cc.c, function static irqreturn_t ti81xx_interrupt(int irq, void *hci)

    I added the line dev_dbg....

    if (musb->int_usb & MUSB_INTR_SOF) {
    musb->sof_cnt++;
    dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr); // bsh007 - adding log to usb
    musb->int_usb &= ~MUSB_INTR_SOF;


    In kernal config - CONFIG_DYNAMIC_DEBUG=y .

    I run it several times and got log (uploaded) and got log with the following line type:

    [ 31.990207] musb-hdrc musb-hdrc.0: CPPI 4.1 IRQ: Tx 4, Rx 0


    Can yo please send me the change needed for function ti81xx_interrupt().


    Regards,
    Shabtai
  • 0 in reply to Shabtai Haim
    TI__Guru**** 153651 points

    You don't need to modify anywhere in the kernel, just enable the debug and capture the log until the issue happens.


    The dev_dbg() is right above 'if (musb->int_usb & MUSB_INTR_SOF)', you don't need to add it again.

    Please post your ti81xx.c for me to check.

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Hi,

    Attached the file ti81xx.c

     

    Regards,

    Shabtai

    ti81xx.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /*
    * Texas Instruments TI81XX "usb platform glue layer"
    *
    * Copyright (c) 2008, MontaVista Software, Inc. <source@mvista.com>
    *
    * Based on the DaVinci "glue layer" code.
    * Copyright (C) 2005-2006 by Texas Instruments
    *
    * This file is part of the Inventra Controller Driver for Linux.
    *
    * The Inventra Controller Driver for Linux is free software; you
    * can redistribute it and/or modify it under the terms of the GNU
    * General Public License version 2 as published by the Free Software
    * Foundation.
    *
    * The Inventra Controller Driver for Linux is distributed in
    * the hope that it will be useful, but WITHOUT ANY WARRANTY;
    * without even the implied warranty of MERCHANTABILITY or
    * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
    * License for more details.
    *
    * You should have received a copy of the GNU General Public License
    * along with The Inventra Controller Driver for Linux ; if not,
    * write to the Free Software Foundation, Inc., 59 Temple Place,
    * Suite 330, Boston, MA 02111-1307 USA
    *
    */
    #include <linux/init.h>
    #include <linux/io.h>
    #include <linux/usb/otg.h>
    #define DEBUG
    #include <linux/platform_device.h>
    #include <linux/dma-mapping.h>
    #include <linux/module.h>
    #include "cppi41.h"
    #include "ti81xx.h"
    #include "musb_core.h"
    #include "cppi41_dma.h"
    #ifdef CONFIG_PM
    struct ti81xx_usbss_regs {
    u32 sysconfig;
    u32 irq_en_set;
    #ifdef CONFIG_USB_TI_CPPI41_DMA
    u32 irq_dma_th_tx0[4];
    u32 irq_dma_th_rx0[4];
    u32 irq_dma_th_tx1[4];
    u32 irq_dma_th_rx1[4];
    u32 irq_dma_en[2];
    u32 irq_frame_th_tx0[4];
    u32 irq_frame_th_rx0[4];
    u32 irq_frame_th_tx1[4];
    u32 irq_frame_th_rx1[4];
    u32 irq_frame_en[2];
    #endif
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Shabtai Haim
    TI__Guru**** 153651 points

    In your version of ti81xx.c,

      1080         if (usbintr)
  1081                 musb_writel(reg_base, USB_CORE_INTR_STATUS_REG, usbintr);
  1082         musb->int_usb = (usbintr & USB_INTR_USB_MASK) >> USB_INTR_USB_SHIFT;
  1083                                 
  1084         //dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr);
  1085 
  1086         if (musb->int_usb & MUSB_INTR_SOF) {

    You have line #1084 commented out, that is why your log does not have the message that I was looking for. Please uncomment it and re-capture the log until the issue happens.

  • 0 in reply to Bin Liu
    Intellectual 390 points

    Hi Bin,

    Sorry about the longs delay in responding your questions, I will try to help to push this case forward.

    I did what you asked (dynamic print) , attached is the file with logs, it is full with prints such as

    "musb-hdrc musb-hdrc.1: usbintr (0) epintr(4000000)"

    I also added to the top of the file the boot messages , just in case you would like to see themmusb.txt

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Elison,

    Thanks for uploading the log, it shows the ep interrupt 0x4000000 flooding which overflows the dmesg buffer, so we lost the log information at the beginning of the failure.

    Please try the following to capture the log differently. Instead of "echo 'func ti81xx_interrupt =p' > ..." as we did to capture the log, can you please apply the follwing patch to capture the usb interrupt log?

    diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c
index 077f6ec..b16519f 100644
--- a/drivers/usb/musb/ti81xx.c
+++ b/drivers/usb/musb/ti81xx.c
@@ -1049,6 +1049,7 @@ static irqreturn_t ti81xx_interrupt(int irq, void *hci)
        musb->int_usb = (usbintr & USB_INTR_USB_MASK) >> USB_INTR_USB_SHIFT;
 
        dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr);
+       dev_err(musb->controller, "usbintr (%x)", usbintr);
 
        if (musb->int_usb & MUSB_INTR_SOF) {
                if (musb->sof_enabled) {
  • 0 in reply to Bin Liu
    TI__Guru**** 153651 points

    Please use this patch instead to capture the log.

    diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c
index 077f6ec..47fbba7 100644
--- a/drivers/usb/musb/ti81xx.c
+++ b/drivers/usb/musb/ti81xx.c
@@ -1044,8 +1044,11 @@ static irqreturn_t ti81xx_interrupt(int irq, void *hci)
                goto eoi;
        }
 
-       if (usbintr)
+       if (usbintr) {
                musb_writel(reg_base, USB_CORE_INTR_STATUS_REG, usbintr);
+               dev_err(musb->controller, "usbintr (%x)", usbintr);
+       }
+
        musb->int_usb = (usbintr & USB_INTR_USB_MASK) >> USB_INTR_USB_SHIFT;
 
        dev_dbg(musb->controller, "usbintr (%x) epintr(%x)\n", usbintr, epintr);
  • 0 in reply to Bin Liu
    Intellectual 390 points

    dmseg_usb2.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    / #
    / # dmesg
    [ 0.000000] Linux version 3.2.0 (bee031@srv608) (gcc version 4.7.3 (Buildroot 2014.05) ) #2 Sun Sep 20 14:12:45 IST 2015
    [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
    [ 0.000000] Machine: AM335x Prince Kernel - Prince_SCM_I00.0042 - (bee031@srv608)
    [ 0.000000] Memory policy: ECC disabled, Data cache writeback
    [ 0.000000] On node 0 totalpages: 65536
    [ 0.000000] free_area_init_node: node 0, pgdat c056dcf4, node_mem_map c05a2000
    [ 0.000000] Normal zone: 512 pages used for memmap
    [ 0.000000] Normal zone: 0 pages reserved
    [ 0.000000] Normal zone: 65024 pages, LIFO batch:15
    [ 0.000000] AM335X ES2.1 (neon )
    [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
    [ 0.000000] pcpu-alloc: [0] 0
    [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
    [ 0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mtdblock10 rootfstype=cramfs rootwait=1 eth=fc:0a:81:c8:c8:e9 mod=M modem_type=4G
    [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
    [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
    [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
    [ 0.000000] Memory: 256MB = 256MB total
    [ 0.000000] Memory: 254088k/254088k available, 8056k reserved, 0K highmem
    [ 0.000000] Virtual kernel memory layout:
    [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
    [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
    [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
    [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
    [ 0.000000] .text : 0xc0008000 - 0xc04e6000 (4984 kB)
    [ 0.000000] .init : 0xc04e6000 - 0xc051b000 ( 212 kB)
    [ 0.000000] .data : 0xc051c000 - 0xc0576ba8 ( 363 kB)
    [ 0.000000] .bss : 0xc0576bcc - 0xc05a1838 ( 172 kB)
    [ 0.000000] NR_IRQS:396
    [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
    [ 0.000000] Total of 128 interrupts on 1 active controller
    [ 0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
    [ 0.000000] omap_dm_timer_switch_src: Switching to HW default clocksource(sys_clkin_ck) for timer1, this may impact timekeeping in low power state
    [ 0.000000] OMAP clocksource: GPTIMER1 at 24000000 Hz
    [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
    [ 0.000000] Console: colour dummy device 80x30
    [ 0.000207] Calibrating delay loop... 718.02 BogoMIPS (lpj=3590144)
    [ 0.117198] pid_max: default: 32768 minimum: 301
    [ 0.117322] Security Framework initialized
    [ 0.117428] Mount-cache hash table entries: 512
    [ 0.117850] CPU: Testing write buffer coherency: ok
    [ 0.118678] devtmpfs: initialized
    [ 0.138748] omap_hwmod: pruss: failed to hardreset
    [ 0.139979] print_constraints: dummy:
    [ 0.140369] NET: Registered protocol family 16
    [ 0.142625] OMAP GPIO hardware version 0.1
    [ 0.145119] omap_mux_init: Add partition: #1: core, flags: 0
    [ 0.147049] omap_i2c.1: alias fck already exists
    [ 0.147401] omap_i2c.2: alias fck already exists
    [ 0.147607] The board is IMOD_SCM
    [ 0.148879] am335x_imod_setup_mac_addr: "ethaddr" parsed from command line: fc:0a:81:c8:c8:e9
    [ 0.148906] am335x_imod_setup_mac_addr: "ethaddr" saved in "mac_addr0": fc:a:81:c8:c8:e9
    [ 0.148921] am335x_imod_setup_mac_addr: saved in "mac_addr1": fc:a:81:c8:c8:ea
    [ 0.148934] am335x_imod_setup_mac_addr: saved in "mac_addr2": fc:a:81:c8:c8:eb
    [ 0.149725] omap2_mcspi.1: alias fck already exists
    [ 0.149946] omap2_mcspi.2: alias fck already exists
    [ 0.150893] edma.0: alias fck already exists
    [ 0.150913] edma.0: alias fck already exists
    [ 0.150931] edma.0: alias fck already exists
    [ 0.169736] bio: create slab <bio-0> at 0
    [ 0.171153] CPCAP init started
    [ 0.171439] CPCAP probe started
    [ 0.171669] CPCAP get voltage
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Hi Bin,

    I applied the patch you suggested and reproduced the issue. unfortunately there are no relevant logs at the time the issue happens.

    Attached is the new log

    Thanks,

  • 0 in reply to Eilon Eyal74533
    Intellectual 390 points

    regdump_musb-hdrc.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    / # cat /sys/kernel/debug/musb-hdrc.1/regdump
    MUSB (M)HDRC Register Dump
    FAddr : 00
    Power : f0
    Frame : 014b
    Index : 0f
    Testmode : 00
    TxMaxPp : 0000
    TxCSRp : 0000
    RxMaxPp : 0000
    RxCSR : 0000
    RxCount : 0000
    ConfigData : 33
    DevCtl : 5d
    MISC : 44
    TxFIFOsz : 07
    RxFIFOsz : 07
    TxFIFOadd : 0780
    RxFIFOadd : 0780
    VControl : 00000000
    HWVers : 0800
    EPInfo : ff
    RAMInfo : 0d
    LinkInfo : 5c
    VPLen : 3c
    HS_EOF1 : 80
    FS_EOF1 : 77
    LS_EOF1 : 72
    SOFT_RST : 00
    DMA_CNTLch0 : 0000
    DMA_ADDRch0 : 00000000
    DMA_COUNTch0: 00000000
    DMA_CNTLch1 : 0000
    DMA_ADDRch1 : 00000000
    DMA_COUNTch1: 00000000
    DMA_CNTLch2 : 0000
    DMA_ADDRch2 : 00000000
    DMA_COUNTch2: 00000000
    DMA_CNTLch3 : 0000
    DMA_ADDRch3 : 00000000
    DMA_COUNTch3: 00000000
    DMA_CNTLch4 : 0000
    DMA_ADDRch4 : 00000000
    DMA_COUNTch4: 00000000
    DMA_CNTLch5 : 0000
    DMA_ADDRch5 : 00000000
    DMA_COUNTch5: 00000000
    DMA_CNTLch6 : 0000
    DMA_ADDRch6 : 00000000
    DMA_COUNTch6: 00000000
    DMA_CNTLch7 : 0000
    DMA_ADDRch7 : 00000000
    DMA_COUNTch7: 00000000
    / #
    / # cat /sys/kernel/debug/musb-hdrc.0/regdump
    MUSB (M)HDRC Register Dump
    FAddr : 02
    Power : f0
    Frame : 0068
    Index : 00
    Testmode : 00
    TxMaxPp : 0000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    and also here is the regdump capture of both USB controllers

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points
    Eilon,

    Is the regdump above captured before or after the issue happened? Comparing the value to that in your first post, it seems to be captured before the issue happened. If so please capture the regdump after the issue happened.
  • 0 in reply to Bin Liu
    Intellectual 390 points
    Hi Bin,
    The regdump was captured after the issue happened .
    since the first dump was captured a while ago I think it would be better to ignore the first regdump and only look at the last one I provided .

    Thanks,
  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points
    Eilon,

    The dmesg log show both USB ports are used, and the register log shows USB1 port seems to ok in host mode and has a device enumerated, and USB0 port seems to be in device mode, but I thought your modem is connected on USB0 port from the information you provided before.

    The issue has been last for months, but still misses some information for me to understand your use case, so please provide the following information.

    - USB0 port works in host-only mode, right? Is the modem connected to USB0 port? If not, what device is on USB0 port?
    - USB1 port is in host-only or otg mode? What device is connected to?
    - Please share your USB portion of the schematics;
    - When the issue happens, please capture *both* the register dump and log of 'cat /proc/driver/musb-hdrc.X'.
  • 0 in reply to Eilon Eyal74533
    Intellectual 390 points
    Hi Bin,
    please let me clarify and further explain about our product .

    Our product is built from 3 main components
    1. A 4G usb modem, its USB rule is peripheral
    2. Sitara board runing linux (one side is a USB host the other is peripheral)
    3. Qualcomm MSM8974 running Android (the MSM8974 modem is disabled) (the usb rule is host only)

    The 4G modem connected to the Sitara musb-hdrc.1 . the modem is peripheral and the Sitara Host. Mode=Host, OTG state: a_host; active
    The modem enumerate 2 CDC-ECM + 1 CDC-ACM

    Sitara musb-hdrc.0 is connected to the QCOM cpu and its rule is peripheral Mode=Peripheral OTG state: b_peripheral; active
    A gadget composite driver is bind to this usb port and it enumerate 3 CDC-ECM + 1 CDC-ACM to the QCOM CPU.
    1 CDC-ECM is used for internal QCOM <-> Sitara communication
    for the other 2 ECM network interfaces we use ip bridge (brctl) to simple pass all IP communication from the QCOM to the modem.
    for the ACM we use socat to pass the traffic from QCOM to the modem

    during the case we describe when DMA is active, 1 of the data interfaces which is bridged simply stop working, the other interfaces works ok. When we use PIO everything works OK during very long stress tests .

    I am working with HW team to produce the HW schematics relevant to the USB part.

    Thanks,
  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,

    Thanks for the clarification. It helps on understanding the use case. We have been focusing on the wrong direction because of the logs/descriptions provided earlier.

    Since the USB traffic runs cross both MUSB ports on AM335x, have you isolated the issue is in MUSB0 peripheral port or MUSB1 host port? You probably need USB protocol analyzer to help the isolation.

    BTY, please also try the the following path to see if it affects anything.

    diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 3f24c05..5544a55 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1959,7 +1959,7 @@ static int musb_schedule(
        best_diff = 4096;
        best_end = -1;
 
-       for (epnum = 1, hw_ep = musb->endpoints + 1;
+       for (epnum = is_in ? 1 : 6, hw_ep = musb->endpoints + epnum;
                        epnum < musb->nr_endpoints;
                        epnum++, hw_ep++) {
                int     diff;
  • 0 in reply to Bin Liu
    Intellectual 390 points
    Hi Bin
    first I would like to thank you for your time patient (I know it is lasting for a long time)

    the issue Always happens on musb-hdrc.0 which is as I wrote above in peripheral mode and is connected to the QCOM CPU.
    some additional information.
    1. The issue always happens on a single interface while the other (other 2 ECM and 1 ACM) works OK.
    2. since It is a ECM interface. After the error condition happens I stop the application on the QCOM CPU which initiate the IP traffic and then I do Ping from QCOM to the Sitara while doing TCPDUMP on the sitara. I can see that I receive the icmp echo request and reply them back, but it seems that the QCOM CPU does not receive them.
    3. the traffic going through the bad interface is RTP (audio+Video) which are a high stream of small packets.

    in addition I applied your patch from above and will let you know if it helps.

    Thanks
  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,

    Can you put a USB protocol analyzer on the MUSB0 port to capture a trace until the issue happens? I 'd like to check if there is any specific data pattern which could cause CPPI lockup.

  • 0 in reply to Bin Liu
    Intellectual 390 points

    Hi Bin,

    I am afraid the the USB bus is on the PCB and we cannot put an external analyzer . can you guide me were I can put printk's to provide the needed info?

    I am able to reproduce the issue now very fast so there will not be a lot of logs

    Thanks,

  • 0 in reply to Eilon Eyal74533
    Intellectual 390 points

    Hi Bin,

    our hardware team managed to connect the USB into an analyzer. but The Ellisys file is bigger than the size permitted . is there a way to attach 46K file?

    Thanks,

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points
    Eilon,

    Please following the instruction below to upload the trace. Please note on step 7 for uploading 'done.now' file.
    ===============
    The ftp dropoff directory 'kachith' was created on 10/26/2015 08:30:01.

    The ftp dropoff directory is a write only directory. Files copied to the dropoff directory cannot be viewed or downloaded. The files will be moved to a pickup area when a file called "done.now" is copied to the dropoff directory or after 48 hours. The dropoff directory will not be available after that time.

    To copy files to the dropoff directory:

    1. Open an ftp session to ftpdrop.ti.com.
    ftp ftpdrop.ti.com

    2. Login with the userid 'anonymous'.
    Name: anonymous

    3. Use your email address for the password.

    4. Change directories to the dropoff directory.
    ftp> cd /pub/share/kachith

    Note: If you are using a graphical ftp client, you will not
    see the hidden dropoff directory name kachith appear
    in the file list. You will need to use a manual
    'Change Directory' or 'CD' command to change into the
    dropoff directory.

    5. Set the file transfer mode to ascii or binary as necessary.
    ftp> bin

    6. Transfer the file.
    ftp> put <file>

    7. Create a file on your local system called "done.now" and copy the
    file to the dropoff directory. This is used to indicate that the
    files in the dropoff directory can now be moved to the pickup area.
    If this file is not copied to the dropoff directory then you will
    have to wait 48 hours before the files are moved to the pickkup area.
    ftp> put done.now

    8. End the ftp session.
    ftp> quit
  • 0 in reply to Bin Liu
    Intellectual 390 points

    Thanks Bin for the detailed instructions. I placed a file called untitled.zip inside the ftp directory. inside this file there is file called untitled.ufo which is Ellisys format.

    you can download the viewer from "http://www.ellisys.com/products/download/visualusb.msi"

    the issue we see is on  EP3 IN, you can filter on EP3 and IN. please let me know if you see anything on your side.

    Thanks a lot for all the help

  • 0 in reply to Bin Liu
    Intellectual 390 points
    Sorry for previous confusion the issue happens on EP1 IN and NOT on EP3 as I previously wrote
  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,

    Thanks for uploading the traces.

    Please bear with me as I never used Ellisys tools before, and its UI is very difficult for me. I don't have a conclusion yet, but please see the attached screenshot of Untitied.ufo trace.


    I am unable to find the option to switch to transfer view, so I assume each IN transfer on EP1 contains 3 transactions with data size 512, 512, and 117 bytes respectively. Please check the highlights in the screenshot, for the very last IN transfer, the 117-byte transaction is received 8+ ms after the 2nd 512-byte transaction, then the device is no longer sending data for 16 seconds until the end of the trace.

    I am not sure why the device stop sending data after the last transfer, also I am wondering if the last IN transfer which has 8+ms delay would cause any issue in the network layer.

  • 0 in reply to Bin Liu
    Intellectual 390 points

    Hi Bin,

    I could not find the way to view an attached file. could you please let me know how to do it?

    as for what you see. please make sure you allow the viewer to present the NACKs by default it would not so you miss the last part of the communication. you can do that by pressing right button and in filter sub menu choose to display NACKs

    Thanks

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points
    Eilon, sorry I forgot to attach the file. I've corrected my previous post, please check the screenshot again.
  • 0 in reply to Bin Liu
    Intellectual 390 points
    Hi Bin,
    when I cat /proc/driver/musb_hdrc.0 before the issue I can see that
    ep1in (hw1): 1buf dma, csr 2404 maxp 0200
    TX DMA0: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    (queue empty)

    after the the issue (this never changes after the issue):
    ep1in (hw1): 1buf dma, csr 3404 maxp 0200
    TX DMA0: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000
    req cf4ea590, -820920080/-814664192
    req cf4ea5d0, -820920080/-815457472
    req cf4ea610, -820920080/-815380992
    req cf4ea550, -820920080/-815382336
    req cf4ea510, -820920080/-814663040
    req cf4ea4d0, -820920080/-815073280
    req cf4ea490, -820920080/-814664576
    req cf4ea650, -820920080/-815390592
    req cf4ea690, -820920080/-814665344
    req cf4ea6d0, -820920080/-821724800

    I think that "tx_complete" is not called for this particular interface and therefore the network is stopped since the TX queue is empty
    do you think It would help to prevent ZLP by preventing the request length from being an exact modulo of of the max packet?

    Thanks,
  • 0 in reply to Eilon Eyal74533
    Intellectual 390 points

    Hi Bin,

    any update?

    Thanks

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,

    If you have control on the host side to not sending modulo of the max packet, sure this will prevent ZLP issue, but the patch #6.4 in the link below already fixes the TX ZLP handling in MUSB drivers, you don't have to change the host driver/application, since you said you have already applied all the patches #6.1~#6.5.

    http://processors.wiki.ti.com/index.php/Sitara_Linux_MUSB_Issues#AMSDK_06.00.00.00

    How long does it take to trigger the issue? I am thinking if it is more efficient to debug it if you can ship me the setup then I can debug it locally?

  • 0 in reply to Bin Liu
    Intellectual 390 points

    Hi Bin,

    I am looking again on how we applied the 6 patch you provided and I see something strange.

    in the 0001-usb-musb-cppi41-transmit-ZLP-using-PIO.patch the first change is :

    @@ -627,7 +627,7 @@ static unsigned cppi41_next_tx_segment(struct cppi41_channel *tx_ch)
    * then send the zero length packet.
    */
    if (!length || (tx_ch->transfer_mode && length % pkt_size == 0))
    - num_pds++;
    + tx_ch->zlp_queued = 1;

    pkt_size = length;

    I can see that in our code the change was done (we have tx_ch->zlp_queued = 1;) But the strange thing is actually outside the patch scope. the line "pkt_size = length;" appears just after the IF statement in your code, but in our code it appears BEFORE the IF statement.

    pkt_size = length;
    /*
    * If length of transmit buffer is 0 or a multiple of the endpoint size,
    * then send the zero length packet.
    */
    if (!length || (tx_ch->transfer_mode && length % pkt_size == 0))
    tx_ch->zlp_queued = 1;

    I looked in our clearcase source control to see what was the baseline and it appears that in our code the line "pkt_size = length;" was always before the IF statement

    is it possible to have your entire drivers/musb (based on AMSDK 06.00.00.00) after you applied the 6 patch. I would like to do manual diff.

    Thanks,

     

     

     

     

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points
    Eilon,

    Thanks for pointing it out. I updated the patch #6.4 on the wiki. Please test it again.
  • 0 in reply to Bin Liu
    Intellectual 390 points

    Hi Bin

    I looked at the patch you sent but it seems that it was not changed. The current patch still has the wrong lines. Also the old patch and the new patch are similar (both in text diff and MD5sum)

    could you please check if there was any issue uploading the new patch to the server

    Thanks,

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,

    I tried to download patch #6.4 again, but I got the newer version, not the first one.
    I attached the patch below in case you still have issue to download it.

    0001-usb-musb-cppi41-transmit-ZLP-using-PIO.patch.gz

  • 0 in reply to Bin Liu
    TI__Guru**** 153651 points

    Eilon,

    Please apply the following patch as while.

    diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 3a7acf7..0b17bf5 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1974,7 +1974,7 @@ static int musb_schedule(
        best_diff = 4096;
        best_end = -1;

-       for (epnum = 1, hw_ep = musb->endpoints + 1;
+       for (epnum = is_in ? 1 : 6, hw_ep = musb->endpoints + epnum;
                        epnum < musb->nr_endpoints;
                        epnum++, hw_ep++) {
                int     diff;
  • 0 in reply to Bin Liu
    TI__Guru**** 153651 points
    Eilon,

    Can you please provide the descriptors of the AM335x USB0 gadget (2ECM+1ACM)? You can connect the AM335x USB0 port to a Linux PC and capture the output of command 'lsusb -v -d <vid:pid>' on the PC.

    Can you also please provide the patch which create the USB0 composite gadget? I don't think the kernel has the composite gadget driver which does 2ECM+1ACM. I have to check the driver to see if the endpoint assignment has to be changed on the gadget side.

    Please also provide the descriptors of the modem on the host port. I will have to check the endpoint assignment change as in the patch above is sufficient.
  • 0 in reply to Bin Liu
    Intellectual 390 points

    Hi Bin,

    first unfortunately the patch you sent is not working (Actually I think you already sent it a few weeks ago)

    1 clarification we have 3 ECM + 1 ACM . out of those 3 ECM,  2 are bridged to the modem and 1 is terminated on the Sitara board (used for Qcom-Sitara control) the ACM is also bridged to the modem. our issue happens only on the interfaces which are bridged to the modem (2 ECM + 1 ACM).

    Attached is the lsub as you asked,

    Thanks,

    lsusb.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    yalone@ayalone-laptop:~$ sudo lsusb -v -d 258d:2000
    Bus 001 Device 002: ID 258d:2000
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 2 Communications
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 64
    idVendor 0x258d
    idProduct 0x2000
    bcdDevice 3.16
    iManufacturer 1 MSIL
    iProduct 2 Eilon
    iSerial 11 d79901081600
    bNumConfigurations 1
    OTG Descriptor:
    bLength 3
    bDescriptorType 9
    bmAttributes 0x03
    SRP (Session Request Protocol)
    HNP (Host Negotiation Protocol)
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 291
    bNumInterfaces 8
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
    Self Powered
    Remote Wakeup
    MaxPower 2mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 2 Communications
    bInterfaceSubClass 6 Ethernet Networking
    bInterfaceProtocol 0
    iInterface 3 CDC Ethernet Control Model (ECM)
    CDC Header:
    bcdCDC 1.10
    CDC Union:
    bMasterInterface 0
    bSlaveInterface 1
    CDC Ethernet:
    iMacAddress 5 0016080299D7
    bmEthernetStatistics 0x00000000
    wMaxSegmentSize 4542
    wNumberMCFilters 0x0000
    bNumberPowerFilters 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x82 EP 2 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0010 1x 16 bytes
    bInterval 9
    Interface Descriptor:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points

    Eilon,


    Please apply the following patch and test it again. It changes the ep assignment on the gadget side.

    diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index a9f58da..2d2d29f 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -175,6 +175,9 @@ ep_matches (
        desc->bEndpointAddress &= USB_DIR_IN;
        if (isdigit (ep->name [2])) {
                u8      num = simple_strtoul (&ep->name [2], NULL, 10);
+               /* ep1-10 for IN, ep11-15 for OUT */
+               if (!(desc->bEndpointAddress & USB_DIR_IN) && num < 11)
+                       return 0;
                desc->bEndpointAddress |= num;
 #ifdef MANY_ENDPOINTS
        } else if (desc->bEndpointAddress & USB_DIR_IN) {
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 075aa5f..b745d66 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1124,15 +1124,18 @@ static struct musb_fifo_cfg mode_4_cfg[] = {
 { .hw_ep_num =  8, .style = FIFO_RX,   .maxpacket = 512, },
 { .hw_ep_num =  9, .style = FIFO_TX,   .maxpacket = 512, },
 { .hw_ep_num =  9, .style = FIFO_RX,   .maxpacket = 512, },
-{ .hw_ep_num = 10, .style = FIFO_TX,   .maxpacket = 256, },
-{ .hw_ep_num = 10, .style = FIFO_RX,   .maxpacket = 64, },
-{ .hw_ep_num = 11, .style = FIFO_TX,   .maxpacket = 256, },
-{ .hw_ep_num = 11, .style = FIFO_RX,   .maxpacket = 64, },
-{ .hw_ep_num = 12, .style = FIFO_TX,   .maxpacket = 256, },
-{ .hw_ep_num = 12, .style = FIFO_RX,   .maxpacket = 64, },
-{ .hw_ep_num = 13, .style = FIFO_RXTX, .maxpacket = 4096, },
-{ .hw_ep_num = 14, .style = FIFO_RXTX, .maxpacket = 1024, },
-{ .hw_ep_num = 15, .style = FIFO_RXTX, .maxpacket = 1024, },
+{ .hw_ep_num = 10, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num = 10, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num = 11, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num = 11, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num = 12, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num = 12, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num = 13, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num = 13, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num = 14, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num = 14, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num = 15, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num = 15, .style = FIFO_RX,   .maxpacket = 512, },
 };
  • 0 in reply to Bin Liu
    Intellectual 390 points

    4274.usb.zipHi Bin,

    I tested the patch you sent but unfortunately it does not solve the issue.

    as you requested I am sending you all the code under drivers/usb were we made our changes .

    our changes touched f_ecm.c, cdc2.c and u_ether.c , you will also see all the patches we applied from TI

    hope this helps

    Thanks

  • 0 in reply to Eilon Eyal74533
    TI__Guru**** 153651 points
    Eilon,

    I reviewed the code but don't have any comment at the moment yet.

    You have mentioned that during your debug, you found adding printk() in the driver makes the issue disappear, do you still remember where in the driver the printk() has been added? Please provide the patch if possible.

    BTY, I use Lecroy USB protocol analyzer for USB debugging.
1 2