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.

AM5728: USB 3.0 Connection Issue AM5728 in Device Mode

Part Number: AM5728

We have a custom designed PCBA utilizing the Sitara AM5728 processor for an application that includes machine control and data acquisition. We use USB 3.0 as our primary communication and data path to an external windows PC so the Sitara is configured in device mode.

We have an issue on some of our prototype boards where the USB will fail to enumerate in SuperSpeed (USB 3.0) mode and will default to High Speed (USB 2.0). We have identified a thermal dependency on these boards where they will connect successfully if heated but will fail at room temperature or lower.

We have also found a workaround using debug commands to shutdown our USB gadget application, unmount the DWC3 kernel module, then restart the USB enumeration process. This will always result in a superspeed connection so we suspect some sort of power up timing or order of operation issue in the firmware.

We have also done some compliance tests with a highspeed oscilloscope that gives us confidence in the hardware. The USB section of the schematic is shown below.

Logs from a Beagle USB Analyzer show that the failure always occurs during the TS1 phase of the polling state, where 9C or 00 starts being sent in place of 4A for bits 6-F.

  • You mention that you have done compliance tests which are passing for the USB3.0 specs and hence I understand that the compliance is not the issue but the intermittent detection of USBSS vs USBHS is the issue.

    reg the schematic review, how is the VBUS detected?

    When startup, is the same debug procedure you have not applicable? ( restarting the USB enumeration).

  • Hi Alex 

    Which SDK you are using ?

    Can you share the pass and fail logs as well ?

    Regards
    Diwakar

  • VBUS runs to the VBUS input on the PMIC. We don't have the VBUSDET output from the PMIC routing to a Sitara IO as in the reference design but I'm not sure that matters in our case since in most cases the PC who would drive VBUS would already be on and connected when our board boots up.

    I'm not sure I completely understand your second question. At startup, we attempted to delay the loading of the usb related kernel modules until later in the boot process because it seemed like Windows was trying to start the process before the Sitara was ready. That did seem to help as previously all boards were showing this issue and now it is confined to about 15% of the boards. We don't have a forced remuneration at boot as it should be the first enumeration.

  • Attached two log files.

    Boot1_SuperspeedConnection_row1391.txt
    PCB connected to windows PC through a USB3 cable, room temperature, then power up. (SuperSpeed Connection at row 1391)

    Boot2_HighSpeedConnection_row1482.txt
    PCB connected to windows PC through a USB3 cable, spray-cooled board, then power up. (HighSpeed Connection at row 1482)

    Boot1_SuperspeedConnection_row1391.txtBoot2_HighSpeedConnection_row1482.txt

  • Just to check, have your h/w team reviewed the usb guidelines for the board design as described here: https://www.ti.com/lit/an/sprack7b/sprack7b.pdf ? see section 2.7.3 and 2.17.

    Also as previous requested, Which SDK you are using?

    Thanks.

  • We have reviewed the USB guidelines and should be in compliance with all of them.

    SDK is TISDK 08.02.01.00

  • Couple of points from the App note (shared above) section 2.17, that I would like to review:

    -1- For USB Device operation, USB VBUS decoupling capacitance should be < 10 µF.

    -2- Ensure the VBUS decoupling capacitance is connected close to USB connector

    Looking at the error Beagle USB Analyzer show, this happening during before the USB chirps, so this looks like some electrical issue.. Can some one from your side comment? 

    Also, on the TI EVM design, we see that there is 0.1uF capacitor on the lines b/n USB_RXP0 & USB_RXN0.. Not sure why this is not on your design. Van you comment?

    Thanks.

  • Please see full USB Analyzer logs for full context. The screenshot shown in the original post was the moment the USB 3.0 enumeration fails and reverts to USB 2.0.

    /cfs-file/__key/communityserver-discussions-components-files/791/Good-Connection.txt

    /cfs-file/__key/communityserver-discussions-components-files/791/Bad-Connection.txt

    We don't currently have any capacitance on VBUS but we can experiment with adding some.

    The reference design has serial caps on the RX lines because of the USB Hub. In our application those caps would be inside the PC. Section 24.7.2.2 of the device TRM shows the typical application of using USB3.0 in device mode with serial caps only on the TX lines.

  • OK, thanks for details.

    Are you able to reproduce this issue on our TI EVM? 

  • As discussed on some other posts, the TI AM572X EVM requires hardware modification for use in device mode. We do have some EVM boards around with this hardware modification from early design work.

    When I attempt to test the USB connection with our latest SD card image in the EVM board, the USB 3.0 enumeration fails but it does not revert back to USB 2.0 as we see on our custom board. Running the workaround code from the original post will force it to connect USB 3.0, just like on our custom board.

  • Thanks Alex for letting us on regarding the EVM testing.

    We are running out of idea to suggests here. We are not sure if it is a hardware or a software/driver issue seen in your designed board.  The TISDK 08.02.01.00 mentioned is the last release for AM57x family on the 5.11 Kernel. 

    Thanks.

  • Please see the full report of the hardware/software configuration (including logs and configuration files) and results from several experiments with old (failing software) and the new patch (passing software)

    Luminex AM5728 USB Connection Issue Feb-05-2024.pptx

  • Is this passing after new patch applied? What changed in old/ new patch?

  • You can refer to pag24 of the "full report". The "new patch" essentially kill and restart our CustomApplication which removes and installs again the
    usb kernel modules. After that we have properly a superspeed connection.

  • Paolo,

    Glad to know that its working now.

  • Vbus capacitance max is 10uF but must have min of 1uF in device mode.

  • Shreyas,

    While the patch is working, we would still like to come to a true root cause for connection failure at boot up.

  • Hello Alex,

    Please give our team some time to look into this and see if we can come up with some new ideas to help root cause.

    Thank you for your patience.

    -Josue

  • Hello Alex,

    Sorry for the delay, Took me some time to find a board that had USB 3 pinned out. None of the AM57 boards have USB 3.0 option for device mode, and I had a week long training as well.

    Found a board with Similar IP that we can try some tests on. 

    On some early testing I am seeing that the board does not enumerate if it remains connected after a reboot. If it is connected after the gadget module is loaded, it enumerates with no issue.

    Best,

    Josue

  • Hello Alex,

    After some work, I have found out that USB 3.0 is not part of our standard SW offering for Linux.

    USB 3.0 is supported by Linux but this is not validated by us in Linux for AM57xx. Please see the AM57x_BuildSheet.xlsx for a list of supported features.

    Best,

    Josue