Hi All,
I have query regarding Default State of USB Device.
We are writting an application to test an newly made USB Device for its
compliance to USB2.0 and some other firmware related things.
In which we have to tes the behaviour of device for all states “Default,
Address and Configured” means whatever the operation device support in
perticular state.
We have successly achieved Address and Configured. We are struggling with
Default State.
According to USB2.0, In Default state device provides the support for
GET_DESCRIPTOR command which will give Device Descriptor and two more
descriptors in reply. We have to get these descriptor while device in
Default State.
But the problem is that Client Driver which is used to access the device
will be activated when device moved to
Powered On -> Default -> Address -> Configured State
When Device Moved to configured State PnP manger will call the DriverEntry
Function which will load our driver. Then only we will be able to test the
device.
So we are facing this bottleneck, any pointer will be highly appreciated!!
Till this time are thinking that we have to write BUS Filter driver which
provide access to to do operation in Default State. How correct this idea is
and how we gonna do this we dont know as we are just analysing the prolem
yet!!
Please give your valuble suggestion!!
Thanks and Regards
Sunil
for testing that your device supports usb descriptor request in default state or not ? its not necessary that you can do that test only using function driver. you can use usbcv test tool provided by usb-if for testing of usb device ch-9 support.
also , when the usb device function driver will be loaded ? only when its enumerated successfully. what this means it had supported dev desc request in default state that why …
and also you can reset usb device after loading of function driver also…
Hi Prajapati,
Thanks for prompt reply.
Ya thats correct that if function driver loaded means device enumerated
successfully but here we not only want to check that device enumerated
properly but it is behaving properly in Default State. Means it is replying
all commands properly in the context.
Same way we are checking for Configure and Address State. We are not getting
any idea where to start with except we have to write Filter driver over hub
driver and stop USBD to configure the device so that it will remain in
Default State.
Regarding usbcv -> it does much of testing on the device but we still want
device to test further.
If you check USBCV for 3.0 it provides Default State Test Cases but not in
2.0. how they doing?? Same way we want in 2.0
Thanks and Regards
Sunil
On Mon, Jul 19, 2010 at 10:37 AM, wrote:
> for testing that your device supports usb descriptor request in default
> state or not ? its not necessary that you can do that test only using
> function driver. you can use usbcv test tool provided by usb-if for testing
> of usb device ch-9 support.
>
> also , when the usb device function driver will be loaded ? only when its
> enumerated successfully. what this means it had supported dev desc request
> in default state that why …
>
> and also you can reset usb device after loading of function driver also…
>
> —
> 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
>
hi sunil,
this is paras
as per usb spec by using set_configuration(0) you can put your device in default state and then also can check your all test cases. you should provide set_configuration(0) reuest support to application from function driver. when your test finished in one mode you can reset and put device in another state to test other states. for set_address i have no idea that you can control it from application or not but default and configured state you can test using this technique.
i thought this is the best way to test it using function driver otherwise you have to write bus driver to do same like usbcv test suite,.
Why are you going through the pain? To validate the hardware? Are you going to ship this filter driver to customers? I don’t think you will get what you need from a usbhub filter driver. Most of these initial state changes occur in usbport itself, with no way for you to hook them. If you want to validate hardware, use a usb bus analyzer.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Sunil Kumar
Sent: Sunday, July 18, 2010 11:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Operation In “Default State” of USB Device
Hi Prajapati,
Thanks for prompt reply.
Ya thats correct that if function driver loaded means device enumerated successfully but here we not only want to check that device enumerated properly but it is behaving properly in Default State. Means it is replying all commands properly in the context.
Same way we are checking for Configure and Address State. We are not getting any idea where to start with except we have to write Filter driver over hub driver and stop USBD to configure the device so that it will remain in Default State.
Regarding usbcv -> it does much of testing on the device but we still want device to test further.
If you check USBCV for 3.0 it provides Default State Test Cases but not in 2.0. how they doing?? Same way we want in 2.0
Thanks and Regards
Sunil
On Mon, Jul 19, 2010 at 10:37 AM, > wrote:
for testing that your device supports usb descriptor request in default state or not ? its not necessary that you can do that test only using function driver. you can use usbcv test tool provided by usb-if for testing of usb device ch-9 support.
also , when the usb device function driver will be loaded ? only when its enumerated successfully. what this means it had supported dev desc request in default state that why …
and also you can reset usb device after loading of function driver also…
—
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
— 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
Doron’s entirely correct.
The Host Controller Driver (HCD) and Hub driver will transition your device through the initial states (Powered On -> Default -> Address -> Configured) automatically. It happens every time anybody plugs a USB device into Windows.
I suppose you could unload the standard Windows HCD and Hub drivers and write your OWN. But besides that, there’s really no way in Windows for you to change or simulate the behavior of these drivers. And, frankly, it’s not necessary or even desirable (because Windows has its own little quirks in terms of moving through those states… and you DO want your device to work with Windows).
What you HAVE to do is get a USB Bus analyzer and watch the exchanges on the bus between Windows and your device. It’s really quite simple. And, really, it’s the only way you can do this.
Peter
OSR
xxxxx@slscorp.com wrote:
as per usb spec by using set_configuration(0) you can put your device in default state and then also can check your all test cases. you should provide set_configuration(0) reuest support to application from function driver. when your test finished in one mode you can reset and put device in another state to test other states. for set_address i have no idea that you can control it from application or not but default and configured state you can test using this technique.
No, this is not correct. Setting configuration 0 returns your device to
the “address state”, where it has a USB address but does not have an
active configuration. The “default state” only exists immediately after
a plugin, before the device has an address. There is no way to
programmatically force a device to return to the “default state”.
Sunil is reposting questions that he already asked on the newsgroups.
Apparently, he was not satisfied with my answers.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> So we are facing this bottleneck, any pointer will be highly appreciated!!
I think that the hardware bus analyzer is the only chance.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> active configuration. The “default state” only exists immediately after
a plugin, before the device has an address. There is no way to
programmatically force a device to return to the “default state”.
More so, if the device successfully moves from default state to more “up” states in all Windows/Linux versions, this is enough testing for me.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Ya you are right tim,
Set_configuration(0) will put device in addressed state. Its better
for sunil to use either embedded host for testing or use any usb bus
analyzer, otherwise with windows the only option is to write a usb
controller driver like for usbcv test suite.
Regards,
Paras Prajapati,
Software Engg,
System Level Solutions(I) Pvt. Ltd.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, July 19, 2010 10:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Operation In “Default State” of USB Device
xxxxx@slscorp.com wrote:
as per usb spec by using set_configuration(0) you can put your device in
default state and then also can check your all test cases. you should
provide set_configuration(0) reuest support to application from function
driver. when your test finished in one mode you can reset and put device in
another state to test other states. for set_address i have no idea that you
can control it from application or not but default and configured state you
can test using this technique.
No, this is not correct. Setting configuration 0 returns your device to
the “address state”, where it has a USB address but does not have an
active configuration. The “default state” only exists immediately after
a plugin, before the device has an address. There is no way to
programmatically force a device to return to the “default state”.
Sunil is reposting questions that he already asked on the newsgroups.
Apparently, he was not satisfied with my answers.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Ya it sets for address state.
Thanks for your valuable suggestion.
Actually these options(usb bus analyzer or any other hardware option ) known
to us. But our requirement is like that
we have to do it programmatically. So we are trying hard to get it done.
Let C, how much success we will get!!
Thanks again guys.
Sunil
On Tue, Jul 20, 2010 at 1:00 PM, Paras Prajapati wrote:
> Ya you are right tim,
>
> Set_configuration(0) will put device in addressed state. Its better
> for sunil to use either embedded host for testing or use any usb bus
> analyzer, otherwise with windows the only option is to write a usb
> controller driver like for usbcv test suite.
>
> Regards,
> Paras Prajapati,
> Software Engg,
> System Level Solutions(I) Pvt. Ltd.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Monday, July 19, 2010 10:50 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Operation In “Default State” of USB Device
>
> xxxxx@slscorp.com wrote:
> > as per usb spec by using set_configuration(0) you can put your device in
> default state and then also can check your all test cases. you should
> provide set_configuration(0) reuest support to application from function
> driver. when your test finished in one mode you can reset and put device in
> another state to test other states. for set_address i have no idea that you
> can control it from application or not but default and configured state you
> can test using this technique.
>
> No, this is not correct. Setting configuration 0 returns your device to
> the “address state”, where it has a USB address but does not have an
> active configuration. The “default state” only exists immediately after
> a plugin, before the device has an address. There is no way to
> programmatically force a device to return to the “default state”.
>
> Sunil is reposting questions that he already asked on the newsgroups.
> Apparently, he was not satisfied with my answers.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
>
>
> —
> 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
>
Sunil Kumar wrote:
Ya it sets for address state.
Thanks for your valuable suggestion.
Actually these options(usb bus analyzer or any other hardware option )
known to us. But our requirement is like that
we have to do it programmatically. So we are trying hard to get it done.
You are wasting your money and your resources. You are trying to solve
a problem that does not need to be solved, because you do not understand
what it is you are asking, or what the specification actually demands.
You are focused with laser-like intensity on a completely
inconsequential point.
If your device is being enumerated and your drivers are being loaded,
then your device is handling the default state correctly. End of
story. Now move on to something that matters.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Ok Tim,
Thanks for your all suggestions. We have to do this experiment and we will
do it!! We are not caring about failure.
Still we have some ideas in mind we will try those. If we found they are not
working we will stop!!
Thanks and Regards
Sunil
On Tue, Jul 20, 2010 at 10:30 PM, Tim Roberts wrote:
> Sunil Kumar wrote:
> > Ya it sets for address state.
> >
> > Thanks for your valuable suggestion.
> >
> > Actually these options(usb bus analyzer or any other hardware option )
> > known to us. But our requirement is like that
> > we have to do it programmatically. So we are trying hard to get it done.
>
> You are wasting your money and your resources. You are trying to solve
> a problem that does not need to be solved, because you do not understand
> what it is you are asking, or what the specification actually demands.
> You are focused with laser-like intensity on a completely
> inconsequential point.
>
> If your device is being enumerated and your drivers are being loaded,
> then your device is handling the default state correctly. End of
> story. Now move on to something that matters.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
sunil kumar wrote:
Thanks for your all suggestions. We have to do this experiment
and we will do it!! We are not caring about failure.
You don’t care if you fail? Why would you even waste your time doing anything then? Just say you failed, and be done with it. After all, you don’t care if you fail, right?