AnsweredAssumed Answered

USB issue from cold-boot BF524

Question asked by ALitz on Jul 20, 2010
Latest reply on Jul 22, 2010 by CraigG



From a cold-boot on certain WinXP machines, the USB intialization sequence is failing:


Issue is as below:


... Bunch of other initialization code....

** configure the controller mode
  return false;

** enable data flow
if( adi_dev_Control( Hdl, ADI_DEV_CMD_SET_DATAFLOW, (void*)TRUE) != ADI_DEV_RESULT_SUCCESS)
  return false;

** enable USB connection with host
  if( adi_dev_Control( Hdl_Cntl, ADI_USB_CMD_ENABLE_USB, (void*)0)  != ADI_DEV_RESULT_SUCCESS)
  return false;

**  wait until the USB is configured by the host before continuing 

The following pends on a semaphore that gets signalled from the callback, when the ADI_USB_EVENT_SET_CONFIG event

is issued through the ISR.


if( VDK::PendSemaphore( kUSB_Configured, 0 /* | VDK::kNoTimeoutError  */) )



Now, under "normal" conditions, once the event triggers, the UsbOtgDevice object (ADI_USBOTG_DEVICE) which is defined in adi_usb_hdrc has properly populated endpoint variables in:





and all is good.  However, when cold-booting, both of these are NULL after the event triggers, resulting in ASSERTS in the adi_dev_read function.


I notice that during the cold-boot sequence, I get about 8 or 9 ADI_USB_EVENT_ROOT_PORT_RESET events before the ADI_USB_EVENT_SET_CONFIG event is triggered, where during a warm-boot, I get 2.


More Info:


Digging deeper into the driver, it looks like the driver decides to use (*(&((UsbOtgDevice).PhysicalEndpointObjects)[1])) and (*(&((UsbOtgDevice).PhysicalEndpointObjects)[2])) instead of 5/6, BUT issuing a call to




looks like it uses a completely different structure (VSDevData) to notify me, the client, which endpoint identifiers I should be using!  The VSDevData is not updated after it is intialized when the driver stack comes up, thus still reports 5/6.    How can I get access to the correct endpoint info?!




Alex Litz