• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 588 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.

Original question:

AM3352: USB STALL issue

AM3352: USB CPPI issue

rei
Mastermind 6135 points
Part Number: AM3352

Hi
My customers implemented STALL processing with reference to Related Post.

1. Register the STALL function.
C:\ti\pdk_am335x_1_0_12\packages\ti\drv\usb\src\musb\usb_musb.c

2. Implement USBDevEndpointStall().
C:\ti\pdk_am335x_1_0_12\packages\ti\drv\usb\src\musb\usb_musb_dcd.c

It was confirmed that STALL processing was performed when USB cable was disconnected.
However, data communication was not successful in the following test case.

Step 1. Connect USB
Step 2. Send data from host side (PC)
Step 3. Disconnect USB
Step 4. Reconnect USB
Step 5. Send data from host (→ When error occur, STALL event occur here)
Step 6. Stop sending data from the host

Testing with DMA_MODE disabled worked fine. So they think there is a problem with CPPI41 DMA.
They checked the difference between DMA_MODE enabled/disabled receive buffers.

When DMA_MODE was enabled, the first 3 bytes disappeared in the received data.
They think this is the cause.

e2e_usb.pdf


Question:
Customers want to use USB driver with DMA_MODE enabled.
Would you tell me how to improve?

PDK : pdk_am335x_1_0_12
BIOS : bios_6_76_00_08

Regards, Rei

  • 0
    TI__Mastermind 41885 points

    Hi Rei,

    From your description, it looks like the CPPI DMA set up upon the USB cable re-connection has some issues. We will try to reproduce the issue here and investigate it more.

    Ming 

  • 0 in reply to Ming Wei
    TI__Mastermind 41885 points

    Hi Rei,

    I tested the USB device MSC example for evmAM335xx (USB_DevMsc_evmAM335x_armExampleProject which uses the CPPI DMA) in Processor SDK RTOS 6.0.0 on AM335x GP EVM. I unplug/plug the USB cable a few times. The program worked as expected.

    After I looked into the program, I found that there is a known issue when CPPI DMA is used along with the cable unpluged. In dev_msc_mmcsd.c line 504 - 512:

    /*

    * In AM335x, CPPI DMA and MUSB could get into a bad state which the USB seems

    * to send bulk IN with bogus data immediately after an IN token received from

    * USB host. This bad state normally happens after USB cable is unplugged

    * while a bulk-in transfer is happening. Cleaning up CPPI/USB pending/stuck

    * transaction does not work yet. Reset the USBSS and USB stack instead for now

    * for AM335x to solve the issue. Please note that this function resets the

    * whole USBSS which resets both USB instances.

    */

    The workaround is to reset the USBSS and USB stack by calling the resetUsb() defined in dev_msc_mmcsd.c.

    You may want to add resetUSB() into you application program.

    Ming

      

  • 0 in reply to Ming Wei
    Mastermind 6135 points

    Hi Ming,
    Thank you for your advice.

    pdk_am335x_1_0_16\packages\ti\drv\usb\example\bios\dev_msc_mmcsd.c
    When resetUSB () was implemented with reference to the above file, disconnection recovery was possible.
    They unplug/plug the USB cable a few times. The program worked as expected.
    However, unplug/plug the USB cable 7~8 times, occurs the following phenomenon.
    ・Abort occur
    ・Complete the setup, but can't work data transfer

    Question:
    Would you tell me how to resolve?

    HW：AM3352 customer board
    PDK : pdk_am335x_1_0_12
    (change drv/usb only to pdk_am335x_1_0_16)
    BIOS : bios_6_76_00_08
    USB：USB bulk transfer + musb

    Regards,
    Rei

  • 0 in reply to rei
    TI__Mastermind 41885 points

    Hi Rei,

    I tested the USB device MSC example for evmAM335xx (USB_DevMsc_evmAM335x_armExampleProject which uses the CPPI DMA) in Processor SDK RTOS 6.0.0 on AM335x GP EVM. I unplug/plug the USB cable 20+ times. The program worked as expected.

    It is using the pdk_am335x_1_0_15 and pdk_am335x_1_0_15

    I do not recommend the mix and match in PDK and SYS/BIOS.

    You can try either with all the components from Processor SDK RTOS 5.1.0 (pdk_am335x_1_0_12) for AM335x or Processor SDK RTOS 6.1.0 (pdk_am335x_1_0_16)

    I plan to download and test the Processor SDK RTOS 5.1.0.

    Ming

  • 0 in reply to Ming Wei
    TI__Mastermind 41885 points

    Hi Rei,

    I did tested the Processor SDK RTOS 5.1.0 for AM335x (pdk_am335x_1_0_12, bios_6_73_00_12). The USB_DevMsc_evmAM335x_armExampleProject did not work for the first unplug/plug. The connect/disconnect bug fix was not in place prior to release 5.3.0.

    I also tried the Processor SDK RTOS 6.1.0 for AM335x (pdk_am335x_1_0_16, bios_6_76_02_02). The USB_DevMsc_evmAM335x_armExampleProject did work for 20+ unplug/plug. I think you will need to move to the latest Processor SDK RTOS for AM335x which is 6.1.0 (pdk_am335x_1_0_16, bios_6_76_02_02).

    Ming

  • 0 in reply to Ming Wei
    Mastermind 6135 points

    Hi Ming,

    Sorry many times. My customers have upgraded, but unplug/plug test fails.
    ・pdk_am335x_1_0_16
    ・bios_6_76_02_02
    ・usb bulk transfer + musb
    ・AM3352 Customer's board

    The details are in the following pdf file.
    2671.e2e.pdf

    I understand that USB_DevMsc_evmAM335x_armExampleProject doesn't reproduce. But they only have AM335x Starter Kit, so it seems difficult to reproduce this issue.

    Question:
    How do we know where Exit()/Abort() is occurring?
    And please tell me registers(structure/variable) to be checked.

    Regards, Rei

  • 0 in reply to rei
    TI__Mastermind 41885 points

    Hi Rei,

    I found a potential problem in the USB bulk driver for AM335x:

    resetUsb --> USB_open() --> USB_open_musb --> usb_osalCreateBlockingLock --> SemaphoreP_create. It will create two semaphores every time it gets called, but they never been deleted. If the plug/unplug cable happened many times, the RTOS heap will be used up, then the RTOS abort will happen.

    The fix is that when the g_resetUsb is set to 1 (to trigger the calling to resetUsb()), the write_Sem and read_Sem should be deleted (by calling usb_osalDeleteBlockingLock).

    Ming

  • 0 in reply to Ming Wei
    Mastermind 6135 points

    Hi Ming,

    The customer's board worked fine. And thank you for your kind support.

    They have a last question.

    Will this fix be included in next pdk Update? (1Q2020)

    Regards, Rei

  • 0 in reply to rei
    TI__Mastermind 41885 points

    Hi Rei,

    I will file a JIRA ticket, but I am not in the position to commit a date for the development team.

    Would you mind mark this thread as "Resolved" Thanks!

    Ming

  • 0 in reply to Ming Wei
    Mastermind 6135 points

    Hi Ming,

    I check pdk every time it is updated.

    I'm really thankful to you.