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
if( adi_dev_Control( Hdl, ADI_DEV_CMD_SET_DATAFLOW_METHOD, (void*)ADI_DEV_MODE_CHAINED) != ADI_DEV_RESULT_SUCCESS)
** enable data flow
if( adi_dev_Control( Hdl, ADI_DEV_CMD_SET_DATAFLOW, (void*)TRUE) != ADI_DEV_RESULT_SUCCESS)
** enable USB connection with host
if( adi_dev_Control( Hdl_Cntl, ADI_USB_CMD_ENABLE_USB, (void*)0) != ADI_DEV_RESULT_SUCCESS)
** 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.
Digging deeper into the driver, it looks like the driver decides to use (*(&((UsbOtgDevice).PhysicalEndpointObjects))) and (*(&((UsbOtgDevice).PhysicalEndpointObjects))) instead of 5/6, BUT issuing a call to
adi_dev_Control( Hdl, ADI_USB_CMD_CLASS_ENUMERATE_ENDPOINTS, (void*)&EnumEpInfo)) != ADI_DEV_RESULT_SUCCESS)
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?!