CCS/PROCESSOR-SDK-AM437X: CCS/PROCESSOR-SDK-AM437X: USB Host MSC addressing problem on custom HW

To locate the problem, i checked the correponding chapter at the TRM.

But I am not sure how to check the relevant things mentioned here:

Regards, Thomas

Hi Thomas,

I have a few questions.

You ported the Processor-SDK-RTOS USB MSC device driver to 3rd party AM437x-based hardware platform?

If so, did you only port the code, or did you integrated the driver with other code?

Did you try the USB host MSC driver without any modification on a TI platform with the same USB stick?

The failure you mention seems to only occur in a single place:

USB_HOST_xHCI_Address_Device():

            /*Check if Command Completion event has come for the Set address command */
            if(TRB_FIELD_TO_TYPE(xhciData->PtrEvent->trb_slotid) == TRB_COMMAND_COMPLETION)
            {
                compCode = Command_Completion_Handler(instanceNumber);

                if (COMP_SUCCESS != compCode) 
                {
                    return (ERR_USB_HOST_SET_ADDRESS_FAILED | compCode);
                }
            }

Command_Completion_Handler():

compCode = GET_COMP_CODE(xhciData->PtrEvent->completioncode);

Have you checked the value returned in compCode? I see many possible failures (TRB Completion Codes) in the xHCI spec.

Have you inspected the traffic on a USB analyzer for the working and non-working cases?

Regards,
Frank

Hi Frank,

my answers to your questions:

You ported the Processor-SDK-RTOS USB MSC device driver to 3rd party AM437x-based hardware platform?

=> Yes, that's correct. We selected the embest-tech.com HW which offers interfaces we used for SW tests

(mainly USB and multiple SPI connectors).

If so, did you only port the code, or did you integrated the driver with other code?

=> I ported the USB host msc example code and added SD card support. This worked fine, but I recognized a "blocking"

behavior of the while loop at xhci_enum() function so I optimized this part for our use. I am able now to "poll" xhci_enum() without

blocking during usb_osalDelayMs(125ms) or xhci_wait_for_event().

Did you try the USB host MSC driver without any modification on a TI platform with the same USB stick?

=> For all tests, I used the same USB stick. Extended code module developed at 3rd party HW is usable without adaptions

because of identical settings on target HW (same USB port, PinMux and so on). 

Have you checked value returned for compCode?

=> Not yet. First I wanted to verify that all required clocks are working (we have replaced TI's board lib and gpio driver by own code).

But I had difficulties to exactly identify what is required for port 1 USB host msc.

Have you inspected the traffic on a USB analyzer for the working and non-working cases?

=> I don't think we have an USB analyzer to do this ....

Regards,

Thomas