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.

AM335x unexpected PING-ACK when Hub is connected to USB1

Hi all,

      I meet unexpected PING-ACK issue when usb host transmit special data packet via usb analyzer.The issue may only occur when the follow conditions are established:

1.A hub is connected to usb host

2.The data packet is transmitted from host to device,and filled with fixed data(0x47).The issue maybe reproduced with other fixed data.

   I use the wince OS.However,I meet the same issue on EVM board with linux os.

    The issue will not occur if we remove hub.The issue can't be reproduced with the same hub on other CPU IC(IMX28(USB2.0),and S3C2416(USB1.1)).It's strange.

  • Please post the Linux version with which you see this issue, also the USB Hub model.
  • Hi Baser,

       The attachment is Linux log without hub model.

       Our HUB model is ST7200USBM made by StarTech.com

    EVM_Linux_Log.zip

  • Xing,

    Please check the information of the OUT transaction right before the PING-ACK, and pay attention to the data toggle in the OUT data packet. I guess what happened was that the previous OUT transaction failed, then host PING the device, and re-transmit the same OUT data packet again.

    The index #70504 shows the data toggle is DATA1. If the data toggle in index #70495 is DATA1 too, my guess above is correct. Otherwise, please attach the bus trace and let me take a look.
  • Hi Bin,

    Thanks a lot!You are right.The data toggle of the out packet is incorrect .However,I feel doubt this issue can't occurs if the data packets is filled without fixed data.Moreover,the data toggle is read from TXCSRH register when  the TX interrupt of the previous  packet is triggered.The usb host driver will record the data toggle if data packet is sent successfully.I don't know how to check it again in host drivers.

  • Xing,

    xing lui said:
    I feel doubt this issue can't occurs if the data packets is filled without fixed data.

    That is right, it only happens with such fixed test pattern (0x47, 0x43), and will not happen in real data transfer. In fact, this is not an issue at all. It is just a re-transmit of the previous transaction, this is defined in the USB Specs to ensure the transfer.

  • Hi bin,

       I think it's right the PING-ACK is due to re-transmit.However,do you know why the fixed test pattern will make the OUT transaction failed much more frequently?I can't duplicate this issue with other CPU IC.so I  think it's not a common issue.

  • This is not a question I can answer as a SW guy, but I guess it is something in the USB PHY analog.

  • Hi Bin,

        Thank you very much.

        I have no idea about how to adjust the PHY analog.Do you think if this issue can be fixed  by adjusting the phy registers' value of usb controller?

  • I am not aware of any possibility to adjust it.

    But what you try to fix anyway? This re-submit is not an issue, and it is compliant with the USB Specs. Most importantly it only happens in certain test data pattern.

  • This is very likely caused by reflection on the DP/DM pair. Certain patterns can exacerbate bus errors by introducing reflections that can confuse one (or both) ends of the connection. Changing the nature of the transmission path by adding/removing devices and/or cables also changes the timing of any reflection which can help/hurt overall functionality.

    Keep in mind that there is no such thing as a perfect transmission path. Every topology instance (board, device, PHY, cable, etc.) is different in some way, even with "identical" components. This is understood in the USB specification and as such USB-IF compliance windows are presented rather than hard compliance targets. Every compliant device will fall differently within this compliance window. Also, USB protocol was designed to be robust to ensure that the inevitable bus error could be gracefully recovered from, which is evidenced in the protocol trace you've provided.

    If you feel that the issue you've described is one that negatively impacts bus performance to an unacceptable degree in your design, my recommendation is that you review the TI High Speed Layout Guidelines white paper and look for board issues that may help reduce the introduction-of and sensitivity-to bus noise and reflections.

    www.ti.com/lit/an/spraar7f/spraar7f.pdf
  • Hi Bin,

       We have serveral USB issues.For example,usb flash storage maybe unmounted when copying files to it. We don't konw the root cause of this issue.However, we can see some errors idenfied by the TXCSRn or RXCSRn when the issue occurs.In order to make the USB Host more stable,we try to solve any problems of usb host if we can reproduce it.

  • Hi,

    Do you see these issues on TI EVM with Linux? or your custom board with WinCE?

    This forum doesn't support WinCE, but if you could explain the issue you have, we might have some comments, just wanted to ensure if the PINK-ACK is the right direction to look.
  • Hi Bin,
    We can also see this issue on EVM with Linux OS.I remember we test this issue with several EVM boards,including ES1.1 and ES2.1.
  • Xing,

    xing lui said:
    We can also see this issue on EVM with Linux OS.

    Do you mean the re-transmit with data pattern 0x47? We are aware of that. As explained, this is not an issue.

    I'd like to understand the real issue you saw on your system.

  • Hi Bin,
    yes.I mean the re-transmit issue.The major real issue is usb flash storege would be unmounted when copying files to it.We can't reprouce it on EVM because we can't set up the same environment.
    It need the following conditions:
    1.USB driver without CPPI DMA.
    2.USB Host need to be connected with HUB.
    3.four usb flash drives are connected to HUB.
    4.The test application need to start several threads,and copy files from and to the four usb flash drives at the same time.

  • Xing,

    For #1, you can disable CPPI DMA in kernel menuconfig:

        Device Drivers  --->
            [*] USB support  --->
                <M> Inventra Highspeed Dual Role Controller
                [*]       Disable DMA (always use PIO)
    

    I believe you don't have issues with the rest 3 conditions.

  • Hi bin,

       As you know,we only use wince platform,and there is no linux expert in our office.we are not familiar with customizing OS and programming application for linux system.

  • Xing, we are willing to answer musb related questions, but unfortunately this forum doesn't support WinCE.
  • Hi Bin,

       I understand it.I will try to reproduce it with linux os.Thank you very much!