Hi,
My driver is based on the UMDF FX2 sample.
My driver has to communicate with the firmware as soon as it goes up (send a few messages, receive a few).
I have tried to place the “wakeup sequence” I wrote in a few places along the code (Device initialization, device configuration), but it seems that these spots were to early in the code, because the driver failed to start.
In the meantime, I have put it in: CMyReadWriteQueue::OnRead,
so when the first application connects, the sequence begins.
But it is just workaround and it should begin sooner, independent of applications’ behavior.
Where is the earliest spot in the code where the driver is already up and ready, and can begin communication?
Thanks,
Gadi
IPnpCallbackHardware::OnPrepareHardware is the first callback where you can touch the hardware. This is an appopriate callback for one time configuration. If this initialization is going to occur every time the device powers up (let’s say after a system standby), IPnpCallback::OnD0Entry is where you want to put your logic
d
Thanks for the quick reply.
I tried putting my logic in both places (I assume that you meant these 2 methods are already callbacks, and I don’t need to create new callbacks for them).
Writing to the device succeeds, but reading from the device causes issues, and results in calling this method (one of the two above, where I have put my logic) again and again, 4 or 5 times, until it stops and I see I get a code 43 error in the device manager (device properties).
I don’t understand why it calls this method again and again, and I don’t know how to debug events which happen at initialization.
My debugging sequence is as follows:
I uninstall the device, install it again, and try to open the debugger during initialization, until it succeeds. This procedure takes a long time and does not always succeed. I’m sure there is a more elegant way to debug initialization, I would appreciate if you can help me on this.
(I tried putting breakpoint in DllMain, DllGetClassObject and CMyDriver::OnDeviceAdd, but it does not halt there).
To perform the read from the device I tried sending one read request (same as in InititatePendingRead), and in another attempt I tried to create my read thread (which does a loop of InititatePendingRead) earlier (it used to be created once in the first time I reached OnRead) , in one of these methods. Both attempts failed and resulted the same way.
So, to summarize, I have 2 questions:
- Why does reading from the device at one of these methods causes the code to re-enter them, and then fails initialization? If reading there is too early, where can I put my read logic?
- How can I debug elegantly initializations events without closing and opening the debugger in hope of catching the driver at the exact moment of initialization?
Thanks,
Gadi
Addition -
I also see that my reads/writes at this stage (OnPrepareHardware \ OnD0Entry) are getting mixed up with the enumeration process (not all GetDescriptor(String lang IDs) are finished. They are interleaved with my write requests). Because I do firmware update, the GetDescriptor transactions fail (they were supposed to be done by now) and I get a reset on the USB line.
How can be sure that they won’t be at this stage? Where in the code can I be sure that I can do my WRITEs when enuneration is completed for sure?
Thanks,
Gadi
xxxxx@n-trig.com wrote:
Addition -
I also see that my reads/writes at this stage (OnPrepareHardware \ OnD0Entry) are getting mixed up with the enumeration process (not all GetDescriptor(String lang IDs) are finished. They are interleaved with my write requests). Because I do firmware update, the GetDescriptor transactions fail (they were supposed to be done by now) and I get a reset on the USB line.
How can be sure that they won’t be at this stage? Where in the code can I be sure that I can do my WRITEs when enuneration is completed for sure?
So, the descriptor requests are not coming from your driver? The
operating system’s enumeration process should be completely finished
before your driver is loaded.
Is this a device that re-enumerates once the firmware is loaded?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The device doesn’t re-enumerate itself. It’s all in one enumeration which happens after boot.
The WRITES happen between GetDescriptor of a ReportDescriptor (followed by GetStatus(Device)) and GetDescriptor(String lang IDs).
It seems that from some reason at this point in the code the OS enumeration process is not done.
xxxxx@n-trig.com wrote:
The device doesn’t re-enumerate itself. It’s all in one enumeration which happens after boot.
The WRITES happen between GetDescriptor of a ReportDescriptor (followed by GetStatus(Device)) and GetDescriptor(String lang IDs).
It seems that from some reason at this point in the code the OS enumeration process is not done.
So, is this a HID device? Is your driver a filter driver?
This seems to be a bit of a design problem. If your device advertises
at connect time that it is a HID device, then I’m not sure it’s allowed
to fail descriptor requests, even while you are loading firmware. This
is one reason why many loadable USB devices do the re-enumeration trick;
in their unconfigured state, they aren’t going to be claimed by any
other drivers.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Can anyone please reply on one of my earlier posts (attached below)?
I could not have solved the issue yet.
Thanks,
Gadi
I tried putting my logic in both places (I assume that you meant these 2 methods
are already callbacks, and I don’t need to create new callbacks for them).
Writing to the device succeeds, but reading from the device causes issues, and
results in calling this method (one of the two above, where I have put my logic)
again and again, 4 or 5 times, until it stops and I see I get a code 43 error in
the device manager (device properties).
I don’t understand why it calls this method again and again, and I don’t know
how to debug events which happen at initialization.
My debugging sequence is as follows:
I uninstall the device, install it again, and try to open the debugger during
initialization, until it succeeds. This procedure takes a long time and does not
always succeed. I’m sure there is a more elegant way to debug initialization, I
would appreciate if you can help me on this.
(I tried putting breakpoint in DllMain, DllGetClassObject and
CMyDriver::OnDeviceAdd, but it does not halt there).
To perform the read from the device I tried sending one read request (same as in
InititatePendingRead), and in another attempt I tried to create my read thread
(which does a loop of InititatePendingRead) earlier (it used to be created once
in the first time I reached OnRead) , in one of these methods. Both attempts
failed and resulted the same way.
So, to summarize, I have 2 questions:
- Why does reading from the device at one of these methods causes the code to
re-enter them, and then fails initialization? Could it be that the driver enters OnPrepareHardware more than once, or tries to initialize itself several times, when it fails? If reading there is too early,
where can I put my read logic? - How can I debug elegantly initializations events without closing and opening
the debugger in hope of catching the driver at the exact moment of
initialization?