USB on Windows 98

[James]

Hello,

I have created an embedded device that uses the PIC18F2550. The device includes the CCS USB stack and enumerates as a composite HID Keyboard and HID Compliant Device (both at the same time). Everything works great under Windows 2000, XP and 7.

However, under Windows 98 SE there is a problem. When I plug the USB cable into the device it enumerates correctly (using the native Windows 98 SE drivers) and the HID Keyboard and HID Compliant Device work as expected. But when I unplug the USB cable from the device, Windows 98 SE hangs (that is, msgsrv32.exe hangs) and I have to re-boot the PC.

I have seen the same behavior on four different Windows 98 SE PCs.

IMPORTANT: I have a commercial USB Keyboard that works correctly when plugged in or unplugged from the same Windows 98 PC. As it turns out, the commercial USB Keyboard also enumerates as both an HID Keyboard and an HID Compliant Device (just like my embedded device), so it's a pretty close approximation to what I am attempting to do--and it works!

How do I resolve this issue and get my device working correctly under Windows 98 SE (and still have it work under Windows 2000, XP and 7)?

Thanks,
James.
 
 

[Jan Axelson]

Is your device truly a composite device? In other words, does it have two or more HID interfaces? If yes, does the hang happen when you are running an application to access the non-keyboard device?

Jan

[James]

Jan,
Thanks for your reply.

Yes, my device has two HID interfaces and is a composite (HID) device. The hang happens whenever I unplug the USB cable. There is no PC application in the picture at this point. I am simply attempting to let the USB enumeration occur (via the built-in Windows 98 HID drivers) and then unplug the USB cable.

Also, I have run the same test with a non-composite version of my device (USB HID Keyboard only) and I get the same result--Windows 98 hangs, but Windows 2000, XP and 7 do not.

James.

[Jan Axelson]

Dr. Watson might offer a clue:

http://support.microsoft.com/kb/275481

Does the working keyboard have its own INF file or its own entry in the Windows HID inf file?

Are you sure the device will have users who are running Windows 98?

Jan

[Guido Koerber]

Jan, never underestimate the inertia of certain parts of the market. We have finally been able to abandon serial mouse protocol in our chips about three years ago, at about the same time we stopped to get support questions for NT 4.0...


Did you compare the descriptors of your device with those of the keyboard that works?

[James]

Jan,

Thanks for all the good suggestions.

The working keyboard does NOT have its own INF file.

There will definintely be Windows 98 users.

I am now using the USBView.EXE tool to compare the USB descriptors of the working keyboard with my device.

One main difference I have found is that the working keyboars is running in SLOW speed and my device is running in FAST speed. Do you think this could be a problem?

Thanks,
James.

[Guido Koerber]

Definitely not. Full speed keyboards are quite common, usually they are the ones with hubs.

Did you check out all descriptors? Not just the HID stuff? Even the string descriptors can have funny effects, I once had a descriptor bug that woul restart certain Windows versions when pluggin in the device.

[James]

Problem solved!

With the excellent help of Darren Rook (Custom Computer Services), this problem has been solved. Here's the deal...

My code was completely ignoring any data that came back from the PC to the HID Keyboard (e.g., the LED status data). That is, I was never calling the usb_get_packet() function to clear the incoming buffer. Apparently Windows 2000/XP/7 are okay with that situation. However, Windows 98 is not okay with that situation. It appears that Windows 98 was sending data to the HID Keyboard and hanging up while waiting for the data to be properly read by the HID Keyboard. Since my HID Keyboard was not "properly" reading the data, Windows 98 was getting messed up.

Thanks to all for you helpful suggestions.

[Jan Axelson]

Thanks for reporting the solution!

Jan

[Guido Koerber]

Now that you mention it Remember hearing something similar from the Apple guys who did the USB stuff of MacOS. There are apparently (or were) some keyboards in the market that implement parts of the default functionality buggy. That prompted the driver writers to make their drivers more forgiving.