USB stack (?) crashing when sending data via both interfaces in composite device

[MB_Inv]

Hello Jan,

we're having the following issue:
- We have implemented a USB composite device (2x Custom HID interfaces), based on SPL (Standard Peripheral Library) from ST and UB lib (from www.mikrocontroller-4u.de) - both libraries due to the FW having been written some years ago...
- On PC side, I use the hidapi driver from signal11 with two separate programs
- Everything is fine until I send packages via both interfaces at the same time. Then, after some time, both interfaces stop responding on read commands from the host programs and once I close the connections, I can't connect again. Also, when disconnecting and connecting the USB cable again, Windows says it doesn't recognize the device and looking at usbview.exe, I can see that Windows couldn't enumerate the USB device. So, I guess the USB stack somehow crashed. However, the rest of the FW seems still to work fine (can see a LED blinking).

So far I checked USB data transmission using "Device Monitoring Studio", but only saw that after some point, the device doesn't answer to read requests any more.
Re-checked also the descriptors, but since this solution is working without problems in another FW(based on CubeMX-generated USB stack) with more or less the same descriptors, I guess the problem doesn't lie there.

Where would you start looking for the root cause? Maybe you have some suspicion? Maybe it's a problem with FIFO buffer memory allocation or something similar?

We've also got the 5th edition of your book in case you could point us to a specific section.

Kind regards,

Markus

[MB_Inv]

I need to add one very important finding:
The USB crash seems to occur only when the device is connected to an USB 3.0 interface on the laptop (in this case, we have only the root hub from the laptop and one hub on our custom HW board). When there is an additional USB 2.0 hub in between, the problem doesn't occur.
In the descriptor, we use USB version 2.0 (0x0200 in BCD).
There is only one configuration, using Full-Speed (FS).

Any clues?

Kind regards,
Markus

[Renate]

Two HID interfaces is somewhat unusual; usually you would simply use multiple reports.
I would wonder if your library doesn't work well with multiple HID interfaces or shares some variables that it shouldn't.
You don't mention what hardware/processor this is.
The link you posted goes to a parking page.

[bpaddock]

LibUSB forked HIDAPI and has been fixing it and keeping it up to date.

The Signal11 version has problems on modern Windows due to "Won't Fix it" statements by its author (accurately) blaming Windows for the problems.

https://github.com/libusb/hidapi

[bpaddock]

HIDAPI Tester is the modern way to test HIDAPI:

https://github.com/todbot/hidapitester

[Jan Axelson]

An alternative is to use a HID Collection for each function:

https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/hid-collections

Just a wild guess, but possibly the USB 3 host is interleaving control transfers to the different interfaces, and the existing code isn't set up to handle that.

A hardware-based protocol analyzer would show detail down to the transaction level and could help to isolate the problem.

[MB_Inv]

Hello and thanks everybody for the suggestions/hints so far!

The reason why we've headed for 2x USB CHID is the following:
- Our devices already have 1 USB CHID interface which is already used by our customers to control our device from their code.
- We want to add a second USB communication without HW change which allows a second program on the customer's host (which is created by us) to get some data out of the device and putting it into the cloud, possibly without the customer having to change his code.
- So, for Multiple Top-Level collections, as far as I understood it, the two (separate) programs would need to somehow share the same interface, distinguishing communication only via report ID. In my sight this would require some significant change in the SW of our customers. That's why we headed for the two interface solution.
- Using a 2nd CHID interface was a) convenient to implement (since the first already worked) and b) has the benefit that we don't need to make the customers install a special .inf file when using Windows (which we want to avoid).
Do you see a different solution (e.g. using Multiple TLCs) here?

Concerning the hidapi driver: I'm aware that it is no longer maintained, however since our solution works for another device (with different libraries), I think that the problem probably lies somewhere in the FW itself. However, thanks for pointing out that it hidapi contains several bugs!

Thanks also concerning the hint with the possibly interleaved control transfers - will check up on this as well!

Additionally, I've also seen crashes when using an USB 1.1 hub...

Kind regards,

Markus

[Jan Axelson]

Again, a hardware-based analyzer would show any errors or problems at the transaction level and thus would help isolate the problem. The older Ellisys models would be sufficient and less expensive than many others.

http://janaxelson.com/development_tools.htm#analyzers

[MB_Inv]

Hi Jan,

thanks - really appreciate your hint!

If I got it right, the benefit of a HW analyzer over a SW one is merely that it doesn't influence USB communication in any way, or are there more benefits?

Would you think Ellisys USB Explorer 200 Basic Edition (€900) would be sufficient?

Kind regards,

Markus

[Renate]

USB 3.0 has made USB 2.0 hardware analyzers a bit cheaper.
Sometimes you can find them used on ebay at reasonable prices.
Other times on ebay they are listed for more than the new price from the manufacturers who are still selling them.

I find that "GPIO" connectivity is helpful sometimes for providing sync to a scope or logging external events for timing considerations.

[bpaddock]

If you see an analyzer on eBay that you think will do the job, don't be afraid to ask if they'll take a lower price.

Sometimes they are there because they are cleaning out a lab or something and they have no idea what they are selling.

I offered $700 for a Elise after seeing that it was not having any interest at $1900 and they accepted the $700.

Using an hardware analyzer gets away from such things as having things work with an Intel hub and not an NEC Hub
and other hairpulling strangeness of the world of USB, when you have a known working standard to use as a reference.

[Jan Axelson]

Yes, Ellisys USB Explorer 200 Basic Edition (€900) would be sufficient.

A hardware analyzer shows the traffic down to the transaction level, for example, for an IN transaction, did the endpoint return data or NAK?

Good advice from the others here.