RawHID and Serial (emulation) problems when changing VID and PID

Status
Not open for further replies.
L

LC_dev

New member
Hello,
I created a small RAW Hid interface with a Teensy 3.1/3.2.
I changed the VID & PID (inside the usb_desc.h file) and all worked ok with both the USB Raw and Serial (emulation) ON. I used this interface for one year and a half now and never had a problem. The interface has been used on Windows 7, Windows 8, Windows 10 and Android, no issues for me or my customers.
Lately, the interface has started to have issues on some Windows machines. I say "some" because I could not identify how the problem arise.
I had an old Windows 8 setup in a secondary partition and I could see that in fact the interface doesn't work here even if on other Windows 8 machines it did work so the release of Windows is not the problem.

After some tests I found out that if I put back the VID and PID to stock Teensy values it all works ok. If I change the VID and PID then I get a strange behaviour on some machines: the serial interface output goes where I'd expect the Rawhid output. Tested with an HID terminal and a TCP terminal connected to teensy gateway I saw that the Serial messages are routed on the HID output.
So I hacked the teensy_gateway program to have it to connect to my new VID and PID to see if I can get the right output : it works fine where the interface works fine, it fails (so serial output is routed to rawhid output) where the interface fails.

Same interface, same firmware on another machine works fine with no problems, no matter which VID and PID I use.

Looking inside the core code (usb_desc, usb_rawhid.c and so on) I could not identify the problem and I'm sure it's not there because, as said, the same interface works fine on the same machine with a different Windows setup.
If I edit the teensy libraries and the usb_desc.h file to totally disable the serial emulated interface everything works OK on every machine.

So, to sum it up:
- PC #1 : Windows 7 ... OK
- PC #1 : Windows 8 ... NOT WORKING (serial output on rawhid output)
- PC #2 : Windows 7 ... OK
- Customer PC #1 : Windows 7 ... OK
- Customer PC #2 : Windows 7 ... NOT WORKING

Does anyone have an idea of why this happens?
 
I found out that if I change these two lines in usb_desc.h
#define RAWHID_INTERFACE 0 // RawHID
#define SEREMU_INTERFACE 1 // Serial emulation
to
#define RAWHID_INTERFACE 1 // RawHID
#define SEREMU_INTERFACE 0 // Serial emulation
I can make the interface works on the systems where it didn't...and the other way around: it fails where it worked.

So this is a hint, but not a solution. At the moment the only solution is to disable the serial emulation completely.
 
LC_dev said:
After some tests I found out that if I put back the VID and PID to stock Teensy values it all works ok. If I change the VID and PID then I get a strange behaviour on some machines: the serial interface output goes where I'd expect the Rawhid output.
Click to expand...

This kinda sounds like the problems that happen when you don't increment bcdDevice for each change. Windows tends to store the prior info in the Windows Registry, and tends to use that info even after it's read the descriptors.

Windows 7 and 8 have seem to have terribly long delays in detecting USB devices, especially ones with multiple HID interfaces. The loading of drivers, even just HID, seems to also take forever (like 30 seconds to a minute or more). Windows XP did this too, but it wasn't as much of a problem because the "New Hardware Wizard" remained on the screen with a silly animation of paper flying across the dialog box from one folder to another. On Windows 7 & 8, a notification appears for just a couple seconds, then fades away. But it's not done... not by a longshot. There's a lot of opportunity for the user to interrupt the process. Often Windows later gets its own HID driver associated, but it certainly gives a lot of opportunity for things to not work if the user tries to do things to "help" get the device installed.
 
PaulStoffregen said:
This kinda sounds like the problems that happen when you don't increment bcdDevice for each change. Windows tends to store the prior info in the Windows Registry, and tends to use that info even after it's read the descriptors.

Windows 7 and 8 have seem to have terribly long delays in detecting USB devices, especially ones with multiple HID interfaces. The loading of drivers, even just HID, seems to also take forever (like 30 seconds to a minute or more). Windows XP did this too, but it wasn't as much of a problem because the "New Hardware Wizard" remained on the screen with a silly animation of paper flying across the dialog box from one folder to another. On Windows 7 & 8, a notification appears for just a couple seconds, then fades away. But it's not done... not by a longshot. There's a lot of opportunity for the user to interrupt the process. Often Windows later gets its own HID driver associated, but it certainly gives a lot of opportunity for things to not work if the user tries to do things to "help" get the device installed.
Click to expand...

Hi Paul,
maybe I don't understand the issue with the bcdDevice setting but I don't think it's the case here : on my Windows 8 setup no Teensy has ever been connected and the interface didn't work from the very beginning.
I think it is a problem of how Windows enumerates multiple interfaces associated with the same VID-PID combination.
If I enable two interfaces (rawhid and seremu in this case) I have the results I posted before: it works on some systems and it doesn't work on others. If I flip the interfaces numbers then I'm in the opposite situation : it works where it didn't and it doesn't where it did.
Enabling only one interface seems to solve the problem even if I still get some "Interface not found" errors. At the moment it's ok to just disconnect the interface and plug it back, no firmware change needed.
I'd call it a temporary patch, not a solution.
 
I'm having a hard time reconciling these 2 statements.

LC_dev said:
maybe I don't understand the issue with the bcdDevice setting but I don't think it's the case here :
Click to expand...

If I flip the interfaces numbers then I'm in the opposite situation : it works where it didn't and it doesn't where it did.
Click to expand...

So you're telling me each system only ever saw the device one way, but you're also saying you tried flipping things. Does this mean you completely re-imaged that Windows machine back to a virgin state before trying the device another way?
 
PaulStoffregen said:
I'm having a hard time reconciling these 2 statements.

So you're telling me each system only ever saw the device one way, but you're also saying you tried flipping things. Does this mean you completely re-imaged that Windows machine back to a virgin state before trying the device another way?
Click to expand...

I'll go through all the steps to see if I can explain it better or, as said, I'm not getting the problem with enumerations.

I have a fully working interface on my Windows 7 machine. I attached this interface to the same machine (same hardware) using Windows 8 and the interface failed. This is the first time ever this O.S. sees the interface and it doesn't enumerate it correctly. I run some tests and saw that the SEREMU output, used for logging, is coming from the raw_hid interface and nothing from teensy_gateway (modified so it could see my VID and PID). So I put back VID and PID to stock and now Windows can enumerate the interface correctly. Please notice: it's the first time Windows sees this new configuration of VID and PID. So now my W8 machine has two cached devices with the only difference of VIDs and PIDs.
Back to W7, everything works fine. W8 again, it doesn't work. So I removed the serial emulation and the interface worked ok (so, this is the second configuration that W8 sees. My VID and PID and SEREMU removed) on both W7 and W8.
Next step: I re-enable SEREMU and swap the number of the interfaces. Now it works on W8 and not on W7. Please notice: this is the third configuration on W8! So ok, it's a problem of enumeration but why on W8 my configuration (the first one) didn't work even if it was the very first time that I plugged the interface in? The 2nd (no SEREMU, stock interfaces order) and 3rd (SEREMU enabled, reversed interfaces order) configurations work fine, the 1st one fails.

Also, I can understand if it's a problem of cached devices, but my customers never saw a Teensy in their life so the problem is not incrementing the bcdDevice after each change: their system never saw changes, just like my W8 didn't at the beginning. W8 coped well with changes, it just could not make the first configuration work.

If I'm not getting the problem please tell me, I'll dig it further on the bcdDevice issue.
 
We had the same problem with multiple Teensy’s running identical firmware and VID/PID plugged in to different computers all running Windows 10. The solution was to modify the connection behavior of the host software. Turns out a few of the Window’s machines were flipping the order of which Teensy interface came first while iterating. But the USB RAW HID is always interface 0 and the serial is always interface 1. During initialization, the open source C library was finding two USB devices with the same VID/PID. But each had a different interface number. Once I added the basic logic to always open the desired VID/PID with interface 0, every Teensy with a custom PID/VID plugged in to a Windows computer is now working flawlessly.

This is the host lib we are using: https://github.com/signal11/hidapi and the parameter to check for a value of zero is hid_device_info::interface_number
 
luni said:
I might be wrong, but isn't the correct way to identify the Teensy RawHID and SerEMU interfaces by their HID usagepage/usage identifier?
Click to expand...

You are probably correct. Searching for the desired interface number solved our problem. I went with the assumption these numbers in file usb_desc.h were fixed:
#elif defined(USB_RAWHID)
#define RAWHID_INTERFACE 0 // RawHID
#define SEREMU_INTERFACE 1 // Serial emulation
 
Status
Not open for further replies.
Back
Top