• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1410 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.

AM5716: USB Bulk transfer interrupt

Masashi Ohhashi
Expert 4805 points

Part Number: AM5716

Hi,

My customer is checking the USB bulk transfer in pdk_am57xx_1_0_14 on AM5716. They found below phenomenons.

1. When the SDK Bulk transfer sample is executed, more than 16,000 interrupts occur before the USB connection is completed. Most of them are XFERNRDY events when in USB_DWC_DCD_EP0_STATE_SETUP state. Is this a normal operation?

2. Can you tell me if there is a way to reduce the interruption of the above XFERNRDY event? (When referring to the Synopsis specification, the XFERNRDY event can be masked via DEPCMD. The XFERNRDY event of the control transfer is described not to be masked.)

3. Which register should I refer to to get the endpoint status, such as STALL status?

Best Regards,

M.Ohhashi

  • 0
    TI__Guru 57015 points

    Hi Ohhashi-san,

    1. 16K of XferNRdy during the setup stage is too much. I look at the code usbDwcDcdEp0EvntHandler() in usb_dwc_dcd.c. When USB_DWD_DCD_EVNT_TYPE_XFERNRDY happens at setup stage (dwc3->ep0State==USB_DWC_DCD_EP0_STATE_SETUP), the driver will issue s a new transfer. on the other hand, according the Synopsis IP spec, "This event can happen when software issues a Start Transfer or Update Transfer. In this case, software must ignore this event because it has already issued the Start Transfer or Update Transfer." This might be the reason why there are so many XferNotReady event. I think the solution is that only issue a new transfer when driver receives two XferNotReady event in a row (not every time). To test the idea, you may want to comment out usbDwcDcdRunSetupXfer(dwc3); to see whether the example still works and the number of XferNotReady event is reduced.

    2. XferNotReady must be enabled for issuing Start Transfer on demand. If you are not implement the Start Transfer on demand, you do not have to enable it.

    3. Try the following:

    Command 3:

    Get Endpoint State (DEPGETSTATE)
    After Get Endpoint State (DEPGETSTATE) command completes, the 32 bits in DEPCMDPAR2 represent the endpoint state to be saved. This includes the current data sequence number, flow control state, and control transfer state (for control endpoints). 

    Best regards,

    Ming

  • 0
    TI__Guru 57015 points

    Hi Ohhashi-san,

    I also tried the USB_DevBulk_evmAM572x_armExampleProject in Processor SDK RTOS 6.0.0 (pdk_am57xx_1_0_15) on AM572x GP EVM along with the Ubuntu 18.04.3 as the USB host. The test passed with total 64 EP0 interrupt, 30 XferNRdy events and 0 XferNRdy event at Setup stage for EP0. I tried both Debug and Release build. The numbers are the same.

    Can you tell me what USB host your customer was using? I was not able to use the Windows machine as the USB host. I heard that Windows machine is more problematic.

    Ming

  • 0 in reply to Ming Wei
    TI__Expert 4805 points

    Hi Ming-san,

    Thank you for your reply. It is helpful information. And I appreciate that you check the program on AM572x GP EVM.

    > Can you tell me what USB host your customer was using?

    They use a windows machine as USB host.

    > Get Endpoint State (DEPGETSTATE)

    My customer didn't find DEMCMDPAR2 in Synopsis specification. Can you tell me where it is listed in the Synopsis specification? DEPCMDPAR2 bit field configuration. (such as which bit stores the End Point State)

    Best Regards,

    M.Ohhashi

  • 0 in reply to Masashi Ohhashi
    TI__Guru 57015 points

    Hi Ohhashi-san,

    Can you ask your customer to use the Linux as the USB host? I heard the Windows machine is problematic with our USB bulk Python script.

    　

    It is Command 3: Get Endpoint State (DEPGETSTATE) writes to Device Physical Endpoint-n Command Register (DEPCMDn). I got it from the DWC_usb3_databook_v2_20e.pdf.

  • 0 in reply to Ming Wei
    TI__Expert 4805 points

    Hi Ming-san,

    Thank you for your suggestion. I will ask my customer it.

    And, I'm sorry to ask you again.

    Could you tell me which page number is described DEPCMDPAR2 in DWC_usb3_databook_V2_20e.pdf?

    Best Regards,

    M.Ohhashi

  • 0 in reply to Masashi Ohhashi
    TI__Guru 57015 points

    Hi Ohhashi-san,

    Page 347, 436, and 438 in DWC_usb3_databook_V2_20e.pdf.

    Ming

  • 0 in reply to Ming Wei
    TI__Expert 4805 points

    Hi Ming-san,

    Thank you very much for your quick response.

    Best Regards,

    M.Ohhashi

  • 0 in reply to Masashi Ohhashi
    TI__Expert 4805 points

    Hi Ming-san,

    I don't have DWC_usb3_databook_V2_20e.pdf. So I don't know where the 32-bit data stored by the DEPGETSTATE command can be referenced to determine the End Point State. Can you answer the details of the 32-bit data (bit field configuration, etc.) obtained by the DEPGETSTATE command?

    Best Regards,

    M.Ohhashi

  • 0 in reply to Masashi Ohhashi
    TI__Guru 57015 points

     

    　

    Hi Ohhashi-san,

    To Issue the Command 3 needs to write 3 in Bit 3 - 0 of the following register:

    Device Physical Endpoint-n Command Register (DEPCMDn)

    Physical_Endpoint_number: 0 ≤ n ≤ 31; Offset: C80C’h + (Physical_Endpoint_number * 10’h) This register enables software to issue physical endpoint-specific commands.

    Write 1 to Bit 10 to enable the execution of the command.

    When Bit 10 becomes 0 means the command execution is completed.

    Command 3: Get Endpoint State (DEPGETSTATE)

    After Get Endpoint State (DEPGETSTATE) command completes, the 32 bits in DEPCMDPAR2 (*) represent the endpoint state to be saved. This includes the current data sequence number, flow control state, and control transfer state (for control endpoints).

    * Physical_Endpoint_number: 0 ≤ n ≤ 31; Offset: C800’h + (Physical_Endpoint_number * 10’h)

    The EP status should be in DEPCMDPAR2, but the Databook did not specify the format of it.

     

    Ming

    　

    　

    　

    6.3.2.5Device Physical Endpoint-n Command Register (DEPCMDn)

    Physical_Endpoint_number: 0 ≤ n ≤ 31; Offset: C80C’h + (Physical_Endpoint_number * 10’h) This register enables software to issue physical endpoint-specific commands.

  • 0 in reply to Ming Wei
    TI__Guru 57015 points

    Hi Ohhashi-san,

    You may also look at the implementation of the function usbDwcDcdRunDEpCmd() in usb_dwc_dcd,c. The command to be used here should be USB_D_EP_CMD_GETEPSTATE.

    Unfortunately, the function did not support the USB_D_EP_CMD_GETEPSTATE very well. You have to make some changes:

    1. Since the USB_D_EP_CMD_GETEPSTATE does not need any parameters, so pDEpCmdParm->parm0, pDEpCmdParm->parm1, pDEpCmdParm->parm2 need to set to 0.

    2. The returned status pointer pStatus needs tp unit32_t and the

    *pStatus = HW_RD_FIELD32(dwc3->baseAddr + DWC_USB_DEPCMD_0(phEpId + 1), DWC_USB_DEPCMD_0_CMDACT);

    should be:

    *pStatus = HW_RD_FIELD32(dwc3->baseAddr + DWC_USB_DEPCMDPAR2_0(phEpId + 1), DWC_USB_DEPCMDPAR2_0_PARAMETER2);

    Ming

  • 0 in reply to Ming Wei
    TI__Expert 4805 points

    Hi Ming-san,

    Thank you for your information and suggestion.

    I will talk about it with my customer.

    I appreciate your support.

    Best Regards,

    M.Ohhashi