USB continous reader setup NOT done in D0

Hi,

I wish to setup my INT endpoint within EvtDeviceFileCreate and not within EvtD0Entry
as it’s “usual”. (I need to control more than 1 EP within the driver, and I don’t really
want to do this D0Entry stuff, as it’s an FX2 thus it doesn’t have any EP “at the start”,
the endpoints only appear after the firmware is loaded into the FX2. Regardless that
I would find it “normal” to start the interrupt pipes when the pipes are atcually
opened and NOT when the device is found).

So within the DeviceFileCreate I both the WdfUsbTargetPipeConfigContinuousReader
and the WdfIoTargetStart.
The both succeed, no BSOD, no invalid status, nothing, BUT
apart from that the reader does NOT start kicking, thus nothing seems to be
coming from the INT pipe.

I would like to mention that the whole stuff was working when the readers were
configured and started within D0.
Any idea?

Thanks,

when do you load your firmware? in PrepareHardware or from data sent from the app after it has opened a handle?

d


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@chello.hu [xxxxx@chello.hu]
Sent: Thursday, October 02, 2008 5:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB continous reader setup NOT done in D0

Hi,

I wish to setup my INT endpoint within EvtDeviceFileCreate and not within EvtD0Entry
as it’s “usual”. (I need to control more than 1 EP within the driver, and I don’t really
want to do this D0Entry stuff, as it’s an FX2 thus it doesn’t have any EP “at the start”,
the endpoints only appear after the firmware is loaded into the FX2. Regardless that
I would find it “normal” to start the interrupt pipes when the pipes are atcually
opened and NOT when the device is found).

So within the DeviceFileCreate I both the WdfUsbTargetPipeConfigContinuousReader
and the WdfIoTargetStart.
The both succeed, no BSOD, no invalid status, nothing, BUT
apart from that the reader does NOT start kicking, thus nothing seems to be
coming from the INT pipe.

I would like to mention that the whole stuff was working when the readers were
configured and started within D0.
Any idea?

Thanks,


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hello Doron,

the FX2 initialization as follows:

  • implemented in the driver the vendor specific commands (i.e. 8051 pin toggling, firmware
    download)
  • use the app. to send down the firmware
  • close down the “raw” (without FX2 firmware) device
  • check the USB tree until the “new” (FX2 loaded) device pops up
  • reopen the “new” device
  • dowload its configuration via the given IOCTL
  • check whether it’s the device I’m looking for (number of EPs)
  • open the pipes one by one
  • abort/reset the pipes one by one (for interrupt EPs I skip the reset, instead of that
    I created my own IOCTL to “purge” the cached interrupt data from the endpoint)

I have to also note that technically I modded the given example from the DDK (the OSRFX2
example), but instead of the code that does the “update” of the status variable (1 byte)
I added a Collection per pipe context and I add the incoming interrupt data to that collection
(within the “oninterrupt” handler) - naturally I also check wheether it is really a “change”
compared to the last data in the collection thus I do not add every received data to the
Collection.

All this concept was actually working while:

  • the pipes were “auto-opened” within SelectInterface
  • start and setup of the continous readers were started in D0

After I removed the “auto-opening” and moved the setup/start within FileCreate
INT endpoints doesn’t seem to be working :frowning:
TraceView shows nothing unusual, everything seems to work as expected, all setup
commands return SUCCESS but my “onInterrupt” per pipe doesn’t seem to be called.

Is there a way to “monitor” the I/O subsystem to find out whether that “floating” URB
that triggers the OnInterrupt per successful I/O read is “existing” in the I/O subsystem
or not?

Or how should I find out what goes nuts?
Thanks Doron,

xxxxx@chello.hu wrote:

the FX2 initialization as follows:

  • implemented in the driver the vendor specific commands (i.e. 8051 pin toggling, firmware
    download)
  • use the app. to send down the firmware
  • close down the “raw” (without FX2 firmware) device
  • check the USB tree until the “new” (FX2 loaded) device pops up
  • reopen the “new” device
  • dowload its configuration via the given IOCTL
  • check whether it’s the device I’m looking for (number of EPs)

Why do you need to do that? Are you using the same VID/PID for the raw
and loaded devices?

  • open the pipes one by one
  • abort/reset the pipes one by one (for interrupt EPs I skip the reset, instead of that
    I created my own IOCTL to “purge” the cached interrupt data from the endpoint)

The abort/reset should be unnecessary. That’s the kind of black magic
voodoo that just masks real problems. The “reset” URB is just a
software thing, resetting data structures within the host controller,
but since your device just came on line, there can’t be anything
dangling there.

Having said that, we usually add a vendor command to the FX2 firmware to
reset the FIFOs from the inside, called through an ioctl. That way, we
know there isn’t anything left over in the buffer.

I have to also note that technically I modded the given example from the DDK (the OSRFX2
example), but instead of the code that does the “update” of the status variable (1 byte)
I added a Collection per pipe context and I add the incoming interrupt data to that collection
(within the “oninterrupt” handler) - naturally I also check wheether it is really a “change”
compared to the last data in the collection thus I do not add every received data to the
Collection.

All this concept was actually working while:

  • the pipes were “auto-opened” within SelectInterface
  • start and setup of the continous readers were started in D0

Where did you do the SelectInterface?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hey Tim,

nope, the VID/PID is different for the raw and the “real” device.
SelectInterfaces is not repositioned, it’s still in PrepareHardware.
Cheers,
t.

On Fri, Oct 03, 2008 at 12:00:15AM -0400, xxxxx@chello.hu wrote:

nope, the VID/PID is different for the raw and the “real” device.

Then why do you need to count endpoints? The PID will tell you whether
you have the unconfigured or configured device.

SelectInterfaces is not repositioned, it’s still in PrepareHardware.

But that selects the zero-bandwidth interface, right? Are you selecting
an interface where your interrupt endpoint has bandwidth?

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

Hi Tim,

the problem seems to be solved :frowning:
Actually it was the Abort/Reset after the open. It made the INT pipe stuck.
Thanks guys for your help!!