Hi,
I am learning to write driver for USB devices. I have downloaded “Sample Driver for USB FX2 Learning Kit” from OSR as my start, but I failed to test program usbfxtest.cpp with this:
while (SetupDiEnumDeviceInterfaces(devInfo,
NULL,
&GUID_OSR_USBFX2LK_INTERFACE,
devIndex++,
&devInterfaceData)) {…}
the function SetupDiEnumDeviceInterfaces always returen false value when I run the program.
I don’t have a “learning kit”, but I happened to have dangle with cypress USB chips. So I defined GUID in usbfx2lk_ioctrl.h file as this:
DEFINE_GUID(GUID_OSR_USBFX2LK_INTERFACE_cy,
0x36FC9E60, 0xC465, 0x11CF, 0x80, 0x56, 0x44, 0x45, 0x53, 0x54, 0x00, 0x00);
GUID GUID_OSR_USBFX2LK_INTERFACE = GUID_OSR_USBFX2LK_INTERFACE_cy;
It seems the program can’t find the device. I am sure I have added
this GUID value as ClassGuid in the inf file and has loaded driver
successfully.
Does anybody knows how to find the device through this GUID and give
me some suggestions? Thanks very much.
And the driver for the cypress device is creating an interface using this
guid?
On Wed, Apr 23, 2008 at 5:07 AM, wrote:
> Hi,
>
> I am learning to write driver for USB devices. I have downloaded “Sample
> Driver for USB FX2 Learning Kit” from OSR as my start, but I failed to test
> program usbfxtest.cpp with this:
>
> while (SetupDiEnumDeviceInterfaces(devInfo,
> NULL,
> &GUID_OSR_USBFX2LK_INTERFACE,
> devIndex++,
> &devInterfaceData)) {…}
>
> the function SetupDiEnumDeviceInterfaces always returen false value when I
> run the program.
>
> I don’t have a “learning kit”, but I happened to have dangle with cypress
> USB chips. So I defined GUID in usbfx2lk_ioctrl.h file as this:
>
> DEFINE_GUID(GUID_OSR_USBFX2LK_INTERFACE_cy,
> 0x36FC9E60, 0xC465, 0x11CF, 0x80, 0x56, 0x44, 0x45, 0x53, 0x54, 0x00,
> 0x00);
>
> GUID GUID_OSR_USBFX2LK_INTERFACE = GUID_OSR_USBFX2LK_INTERFACE_cy;
>
> It seems the program can’t find the device. I am sure I have added
> this GUID value as ClassGuid in the inf file and has loaded driver
> successfully.
>
> Does anybody knows how to find the device through this GUID and give
> me some suggestions? Thanks very much.
>
> —
> 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
>
–
Mark Roddy
yes, the cypress device uses this guid
yes, it is plugged in.
i also tried to remain it plug in and restart the computer. but i still failed to use SetupDiEnumDeviceInterfaces
I have not gone through USB learning kit test application code but
please use GetLastError to obtain the actual error code.
If you are having Visual Studio IDE, then the description of error
lookup may help to some extent.
Regards.
On Wed, Apr 23, 2008 at 7:37 PM, wrote:
> yes, it is plugged in.
>
> i also tried to remain it plug in and restart the computer. but i still failed to use SetupDiEnumDeviceInterfaces
>
>
>
> —
> 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
>
xxxxx@hotmail.com wrote:
I am learning to write driver for USB devices. I have downloaded “Sample Driver for USB FX2 Learning Kit” from OSR as my start, but I failed to test program usbfxtest.cpp with this:
while (SetupDiEnumDeviceInterfaces(devInfo,
NULL,
&GUID_OSR_USBFX2LK_INTERFACE,
devIndex++,
&devInterfaceData)) {…}
the function SetupDiEnumDeviceInterfaces always returen false value when I run the program.
I don’t have a “learning kit”, but I happened to have dangle with cypress USB chips. So I defined GUID in usbfx2lk_ioctrl.h file as this:
DEFINE_GUID(GUID_OSR_USBFX2LK_INTERFACE_cy,
0x36FC9E60, 0xC465, 0x11CF, 0x80, 0x56, 0x44, 0x45, 0x53, 0x54, 0x00, 0x00);
GUID GUID_OSR_USBFX2LK_INTERFACE = GUID_OSR_USBFX2LK_INTERFACE_cy;
There’s no need to define this yourself. You’ll find it in
GUID_DEVCLASS_USB in <devguid.h>. That hint by itself should be enough
to pinpoint your problem, although I will reveal everything in a moment…
> It seems the program can’t find the device. I am sure I have added
> this GUID value as ClassGuid in the inf file and has loaded driver
> successfully.
>
> Does anybody knows how to find the device through this GUID and give
> me some suggestions? Thanks very much.
>
…
> yes, the cypress device uses this guid
>
No, it doesn’t – not in the way you’re trying to use it. That GUID is
the install class GUID for USB controllers. That is NOT a device
interface GUID. Search for 36fc9e60 in your \windows\inf directory, and
you will see that.
The default Cypress drivers do not register any device interfaces. So,
instead of SetupDiEnumDeviceInterfaces, you should use
SetupDiGetClassDevs instead.
By the way, if you decide to release this device to the real world, you
NEED to choose a different install class. Cypress made the mistake of
releasing their samples in the USB class (GUID_DEVCLASS_USB), apparently
in the belief that it was for “generic USB devices”. That’s not true.
That install class is designed for USB hubs and controllers. It is
trivially easy to define your own install class, if none of the generic
ones fit. Just create your own GUID and name it in your INF file.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</devguid.h>
>I have not gone through USB learning kit test application code but please use GetLastError to >obtain the actual error code. If you are having Visual Studio IDE, then the description of error >lookup may help to some extent.
Hi Uday,
thanks for your information. I can get error code through GetLastError, but where can I find what this error code mean? for example, what does it mean when GetLastError returns “0x59”? thanks.
>There’s no need to define this yourself. You’ll find it in GUID_DEVCLASS_USB in <devguid.h>. >That hint by itself should be enough to pinpoint your problem, although I will reveal everything in >?a moment…
Hi Tim,
thanks for your reply. I googled definition for class GUID and device interface GUID, but now I am confused.
To my understanding, class GUID is a GUID for a group of devices, such as GUID_DEVCLASS_USB is defined for USB samples while each USB device has its own identifier, i.e. device interface GUID. Is this correct? If my understanding is right, there should be two ways to access an USB device:
a) through unique device interface GUID. If I know this, I can use CreateFile to access it. The question is that how can I know its device interface GUID? Does it define in inf or some place else?
b) I can enum class GUID until I find the device I need. Then two questions arise:
b1) How can I know the device enumerated is the device I need? I don’t know its device interface GUID, either.
b2) As you have mentioned, the Cypress example driver has used two functions as this:
devInfo = SetupDiGetClassDevs(&GUID_OSR_USBFX2LK_INTERFACE,
NULL,
NULL,
DIGCF_PRESENT | DIGCF_DEVICEINTERFACE);
…
while (SetupDiEnumDeviceInterfaces(devInfo,
NULL,
&GUID_OSR_USBFX2LK_INTERFACE,
devIndex++,
&devInterfaceData)) {…
The SetupDiGetClassDevs always return a pointer to devInfo, but SetupDiEnumDeviceInterfaces always returns false. Can you help me to understand what happened? Thanks very much.
best regards</devguid.h>
> for example, what does it mean when GetLastError returns “0x59”? thanks.
See http://msdn2.microsoft.com/en-us/library/ms681381(VS.85).aspx
> a) through unique device interface GUID. If I know this, I can use CreateFile to access it. The question is that how can I know its device interface GUID? Does it define in inf or some place else?
GUID is not unique per device. You use DevicePath to open the device, guid is a part of it. There are a couple of ways to identify your device, for example using device’s registry properties. The toaster sample from DDK could be a good reference (EnumExistingDevices() func from exe/notify.c).
> for example, what does it mean when GetLastError returns “0x59”? thanks. See http://msdn2.microsoft.com/en-us/library/ms681381(VS.85).aspx
thank you. I will check this.
>GUID is not unique per device. You use DevicePath to open the device, guid is a part of it. There are a couple of ways to identify your device, for example using device’s registry properties. The toaster sample from DDK could be a good reference (EnumExistingDevices() func from exe/notify.c).
Thanks for your reply. I checked notify.c for EnumExistingDevices and I found it is like what I have seen in cypress example driver done. All use SetupDiGetClassDevs to return handle and use SetupDiEnumDeviceInterfaces to enumerate devices. The program will use SetupDiGetDeviceInterfaceDetail to find devInterfaceDetailData->DevicePath and then use this DevicePath as handle to manipulate device. I hope I have understood this right.
But when I run this program, I always got false from SetupDiEnumDeviceInterfaces, I tried to use code = GetLastError() followed SetupDiEnumDeviceInterfaces like
while (SetupDiEnumDeviceInterfaces(devInfo,
NULL,
&GUID_OSR_USBFX2LK_INTERFACE,
devIndex++,
&devInterfaceData)) {…}
code = GetLastError();
The code shows it is 259, ERROR_NO_MORE_ITEMS, which indicates “No more data is available”. I was confused by this. Why there is no data? absolutely there are devices attached to USB bus, Do you know the reason? Thanks very much.
hello skyworld,
“what does it mean when GetLastError returns “0x59”?”
if you are using visual studio then here is a quick way to find description of the result
Go to the watch window
then write like this "0x59,hr " -> this will give you the description of what this code means
regards
>if you are using visual studio then here is a quick way to find description of the result Go to the watch window then write like this "0x59,hr " -> this will give you the description of what this code means
thanks very much.
xxxxx@hotmail.com wrote:
thanks for your reply. I googled definition for class GUID and device interface GUID, but now I am confused.
To my understanding, class GUID is a GUID for a group of devices, such as GUID_DEVCLASS_USB is defined for USB samples while each USB device has its own identifier, i.e. device interface GUID. Is this correct?
No. A device class GUID is specified in an INF file. Every device INF
file has a class in its [Version] header, and every device belongs to
one device class. That class determines where it gets listed in Device
Manager, and it determines which class GUID you need to use in
SetupDiGetClassDevs to find the device.
A device interface GUID is created by IoRegisterDeviceInterface. A
driver has to specifically register itself into a particular device
interface. There is no automatic registration. The stock Cypress
drivers DO NOT register any device interfaces. They create their own
symbolic link file names (usually \.\EzUsb-0).
A device interface is similar in many ways to a COM interface. A COM
interface promises a certain functionality. Many different objects can
implement the same COM interface, and an object does not have to
implement ANY COM interfaces. Same thing here. A device interface is a
way for drivers to offer certain functions. Several drivers can
register for the same interface, or a driver can register none at all.
The stock Cypress drivers do not register any.
If you are really just trying to open a stock Cypress driver, skip all
of the SetupDi magic and use their name:
hDriver = CreateFile( “\\.\EzUsb-0”, … );
If my understanding is right, there should be two ways to access an USB device:
a) through unique device interface GUID. If I know this, I can use CreateFile to access it. The question is that how can I know its device interface GUID? Does it define in inf or some place else?
No. A device interface GUID is not unique to a driver, and the only way
to learn if one is registered is by having the driver writer tell you so.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 24, 2008 10:36 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to find device through GUID
A device interface is similar in many ways to a COM interface. A COM
interface promises a certain functionality. Many different
objects can
implement the same COM interface, and an object does not have to
implement ANY COM interfaces. Same thing here. A device
interface is a
way for drivers to offer certain functions.
Nice theory. Just yesterday I noticed there is some MS (probably) driver
which registers one of interfaces documented in WDK and which doesn’t
implement basic IOCTLs documented there. It causes failure when we
enumerate our devices which use the same interface :-/ Needs more
investigation.
No. A device interface GUID is not unique to a driver, and
the only way
to learn if one is registered is by having the driver writer
tell you so.
Rather bold statement. I usually use WinObj tool to find which
interfaces are registered for loaded drivers. They’re just symbolic
links with structured names contaning interface GUID. Maybe it is
undocumented (I’m not sure) but not impossible.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
xxxxx@probo.com wrote:
No. A device class GUID is specified in an INF file. Every device INF file has a class in its [Version] header, and every device belongs to one device class. That class determines where it gets listed in Device Manager, and it determines which class GUID you need to use in SetupDiGetClassDevs to find the device.
Does this mean if I use SetupdiGetClassDevs and SetupDiEnumDeviceInterfaces with this GUID (used in INF) then I can found all devices listed in HKLM\System\CurrentControlSet\Control\Class\xxxx (GUID) ?
Thanks very much.
skyworld wrote:
Does this mean if I use SetupdiGetClassDevs and SetupDiEnumDevice-
Interfaces with this GUID (used in INF) then I can found all devices
listed in HKLM\System\CurrentControlSet\Control\Class\xxxx (GUID) ?
No, you’re confusing setup class and device interface class (again). The GUID in the INF controls into which device class (i.e. in Device Manager) a device installed. The device interface class GUID uniquely identifies your contract with the owner of the device interface.