Bug in adi_usb_otg.c ( host mode, device enumeration )

I've been looking at the Host OTG USB Drivers, as our application will need to communicate with a 3G/4G modem all nearly all devices currently are USB based.

I'm very new to USB Device drivers and we just using the USB Mass Storage driver ( our software alreay integrates the FSS ), and I've been looking at the device enumeration aspects using the Debugger.

I noticed that when I plugged in a USB RS232 Converter ( this particular one is and FTTI chip ) the enumerated Device Descriptor was corrupted.

After alot of debugging I've tracked the issue down to the EnumDeviceStateMachine function in adi_usb_otg.c file.

in the

   case DEP_GET_DEV_DESCRIPTOR_1: is the line

          memcpy(pUsbOtgHostData->pRemoteDeviceObj->pDeviceDesc,pBuffer->Data,DEVICE_DESCRIPTOR_LEN);

but for this particular device the descriptor is delivered in a 16 byte transaction then a 2 byte transaction, thus the buffer being coppied into the pDeviceDesc only has the last 2 bytes resulting in a corrupted device descriptor.

I've modifed the line to read

          memcpy(pUsbOtgHostData->pRemoteDeviceObj->pDeviceDesc,pDevD, DEVICE_DESCRIPTOR_LEN);

and that from my testing now results in a complete device descriptor being give back to the upper level.

If this is not the place to report bugs please let me know.

If there is any more information that migh help me write a usd host mode driver please let me know as there appear to be very little documentation on host mode.

Development Setup

VisualDSP++ V5.0 Update 10

VDK based project

BF548 EzKit

Parents
    •  Analog Employees 
    on Jul 2, 2013 7:37 PM

    Thank your for the clarification. It appears like with full/low speed devices the handler is returning prematurely. We should stay in the data phase until the entire data is accumlated and then process it.Thank you for reporting the problem, we will log a bug for this problem and schedule the fix in the subsequent releases.

    -Srinivas.

Reply
    •  Analog Employees 
    on Jul 2, 2013 7:37 PM

    Thank your for the clarification. It appears like with full/low speed devices the handler is returning prematurely. We should stay in the data phase until the entire data is accumlated and then process it.Thank you for reporting the problem, we will log a bug for this problem and schedule the fix in the subsequent releases.

    -Srinivas.

Children
No Data