Objective Development Forums

I can't get any software to open the usb device in windows. The firmware is on the microcontroller and works, I can see the device in my computer->properties->hardware->DeviceManager...etc

The combination of the firmware and commandline app work in both linux and osx. But the commandline can't open the device in Windows.

Here is the error I get (debug turned on)

C:\Documents and Settings\xxxx\Desktop\commandline>powerSwitch.exe
checking HID path "\\?\hid#vid_046d&pid_c051#6&3349e8b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
opening failed: 5
checking HID path "\\?\hid#vid_16c0&pid_05dc#6&38d00f32&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
opening failed: 5

That second device should be it. Why is it garbled? Why can't I open it? I'm frustrated, have no idea what's going on.

Thanks, really appreciate your help.

Since the open fails, the device may be opened by another application on your machine. Don't know what error code 5 means, though.

How can it be opened? I'm registering it as an HID Keyboard, could windows be locking the device?

Thanks for your help!

PowerSwitch is not registering as a HID. If you have modified it to be HID, you may need the filter versin of the libusb-win32 driver.

No dice = (

I can't figure it out. Is there any reason why my USB path looks all funky?

Also, this is the line that's being called: DEBUG_PRINT(("opening failed: %d\n", (int)GetLastError()));

Where is the getlasterror funciton and what does error code 5 mean?

Thanks again for your help.

Best,
Jason

Sorry, don't know the answers.

But where the hell is this line of code located in powerSwitch.c?

Well, this actually isn't from powerswitch. I put together two different projects, powerswitch and the usbbootloader, both from obdev. That line is from usb-windows.c



But when I compile powerswitch and execute it, it says it can't find the device either...

Thanks

snookie wrote:How can it be opened? I'm registering it as an HID Keyboard, could windows be locking the device?

Thanks for your help!

Windows locks all HID devices that are mice or keyboards, no matter how many there are.
If your using the windows DDK (native calls) to try to communicate with a locked device, the only way is by using feature reports.
To open the device and not get error 5, you must open the device for ACCESS_TYPE_NONE



Then once the device is found, use the handle to send or get a feature report using USB_HID_REPORT_TYPE_FEATURE.

You must also implement feature reports on you device side firmware (AVR).

Bob.

Awesome, I'll give this a shot and post my success. Awesome advice, thanks for the help.

Best,
Jason

Ah, I overlooked that this is a keyboard. Good to know how keyboards and mice can be opened!

BTW: Please don't use the shared USB PID for HID devices with a keyboard. Windows permanently attaches the keyboard driver to this PID which causes all kinds of troubles.

Christian -

Sorry for the stupid question..

What do you mean by the following comment:

BTW: Please don't use the shared USB PID for HID devices with a keyboard. Windows permanently attaches the keyboard driver to this PID which causes all kinds of troubles.

Is that 0x5dC, or is that the string, HIDKeys/HIDBoot, etc

Just to make sure, I can change either the string or number to some random value, if and only if I'm using the same VID, is that correct?

What exactly is the problem if I leave it as is? Won't I have the same problem if I change it, same problem, different PID? Or because this is a different project, I should change the PID...

Thanks, you guys are awesome.

Best,
Jason

A VID/PID pair identifies a device type. No two device types may share the same VID and PID. E.g. you can't have a keyboard and a mouse with the same VID and PID, not even two different types of keyboard.

To ensure that nobody else uses a given pair of VID and PID values, usb.org maintains a registry of VID values. If you pay enough money, you can get a VID and manage the PID values yourself.

This is not viable for hobbyists since the VID costs at least 2000 USD. We have therefore worked out a mechanism how the same VID/PID pair can be shared among different device types. You must adhere to certain rules to ensure that this works. See the file USBID-License.txt in the usbdrv directory.

If you break one of the rules, e.g. use 0x5dC for a keyboard, other devices which use this PID (e.g. AVR programmers or whatever) won't work on your computer. The PID is associated with a keyboard driver which is unsuitable for the programmer. If you distribute your device, others will have these troubles and you or the manufacturer of the programmer receive support requests. If you don't distribute it, all those troubles are your own and maybe mine, because you ask me for support...

Ah okay, I understand. Thanks a lot Christian.

Best,
Jason

So I finally had a chance to get a crack at this and I unfortunately hit a snag. Like you mentioned, I can send control signals down to the device with:

usbSetReport(dev, USB_HID_REPORT_TYPE_FEATURE, buffer, 4);

However, in the firmware, if I want to receive any data at all, it looks like I need to do implement usbfunctionwrite and if I want to send back data I have to implement usbfunctionread? Is that correct?

Where as before, I can do all these things in usbfunctionsetup with bRequest, wValue.bytes, wValueIndex, and return the usb message pointer?

Sorry for so many questions, it looks like I have to do a lot of extra work just to support windows and I'm very frustrated, because my firmware 'was' 100% done.

Thanks for all your help, appreciate it.

Best,
Jason

To receive data, you must implement usbFunctionWrite(). If you want to send data, you can still use the message pointer mechanism. The result is the same, except that you need to have the data in a static buffer beforehand. If you decide to implement usbFunctionRead(), you can generate the data on the fly.