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.

TMDX654IDKEVM: USBHostControlTransfer

Part Number: TMDX654IDKEVM

Hi,

still using SDK: PROCESSOR-SDK-RTOS-AM65XX_07_01_00_14.

while adapting the USB-Host example to interface an USB-UART adapter to the AM65xx I have a problem using the USBHostControlTransfer for writing data via control pipe to the device. Reading is working fine. To have some more information I expanded the function with printing out the content of the stages.

At first a successful read:

Setup Stage:
control_trb->bmRequestType  = 0xc1
control_trb->bRequest       = 16
control_trb->wValue         = 0
control_trb->wIndex         = 0
control_trb->wLength        = 19
control_trb->transfer_len   = 8
control_trb->flags          = 0x00000841
Data Stage:
normal_trb->bufferlo        = 0x701b0708
normal_trb->bufferhi        = 0x00000000
normal_trb->transfer_len    = 19
normal_trb->flags           = 0x00010c01
Status Stage:
normal_trb->bufferlo        = 0x00000000
normal_trb->bufferhi        = 0x00000000
normal_trb->transfer_len    = 0
normal_trb->flags           = 0x00001021
Event:
PtrEvent->command_trb_ptr_lo = 0x7009ab60
PtrEvent->command_trb_ptr_hi = 0x00000000
PtrEvent->completioncode     = 0x01000000
PtrEvent->trb_slotid         = 0x01018001
Command_Completion_Handler. byEventRingIdex=9. xhciData->PtrEvent=0x7009af50

then I try to write configuration data to the device but this failes with compcode 4.

Setup Stage:
control_trb->bmRequestType  = 0x41
control_trb->bRequest       = 0
control_trb->wValue         = 1
control_trb->wIndex         = 0
control_trb->wLength        = 0
control_trb->transfer_len   = 8
control_trb->flags          = 0x00000841
Data Stage:
normal_trb->bufferlo        = 0x00000000
normal_trb->bufferhi        = 0x00000000
normal_trb->transfer_len    = 0
normal_trb->flags           = 0x00010c01
Status Stage:
normal_trb->bufferlo        = 0x00000000
normal_trb->bufferhi        = 0x00000000
normal_trb->transfer_len    = 0
normal_trb->flags           = 0x00001021
Event:
PtrEvent->command_trb_ptr_lo = 0x7009ab90
PtrEvent->command_trb_ptr_hi = 0x00000000
PtrEvent->completioncode     = 0x04000000
PtrEvent->trb_slotid         = 0x01018001
Command_Completion_Handler. byEventRingIdex=10. xhciData->PtrEvent=0x7009af60
USBHostControlTransfer returns 4

A following read stalls while waiting for the xhci_wait_for_event. This function never returns.

What can cause this behaviour?

Regards,

Stef

  • Hi,

    Can you explain the procedures you are using for your use case for reproducing the issue.

  • Hi,

    I'm using the same procedures as the MSC (adapting evaluation of all the descriptors). After doing the initialization stuff the device is enumerated successfully. So I continue with do some device configuration using the control pipe  as explained using vendor specific bRequests and calling USBHostControlTransfer. But the write commands failes with no further error codes what happened.

    Is there a way to trace the data stream going out of the host and the data received from the slave directly before processing? The documentation in the TRM gives no hint how to access the data. I do not have a HW-USBsniffer that can be inserted between the host and the device.

  • Hi,

    vendor specific bRequests

    What are these? In the above logs, i noticed bRequests as 16 and 0. Is this what you are actually passing in control transfer?

    TI RTOS driver is capable of handling the standard request defined by usb.org. You can also see the definition @ pdk\packages\ti\drv\usb\src\usb_func\device\usb_dev_dman.c : 

    Is there a way to trace the data stream going out of the host and the data received from the slave directly before processing?

    You can analyze using usbAnalyzer only. No other way.

  • Hi,

    I realized that the USB-Host functionality of the TI-RTOS is very rudimentary. As an example the TRB-ring mechanism with the cycle bit as required in the spec 4.9.2. is not implemented. So that was one reason for the behaviour. I have to add the basic functionality needed.

    I think it makes no sense to continue this discussion. You can close this item.