USB Host: Corrupted Descriptor Parsing

[samblenny]

Currently (10.0.0-beta.2) the usb.core.Device API sometimes returns null values (vid/pid of 0) or strings with random garbage when you try to access the .idVendor, .idProduct, .serial_number, .product, and .manufacturer properties of usb.core.Device.

I know this is very vague, but I haven't figured out how to reproduce it consistently. I've taken to using my own USB device descriptor parser as a workaround, so I haven't researched it carefully yet.

I'm posting this issue at tannewt's request to split out one of the points I mentioned in USB Host Improvement Quest Umbrella Issue #10551. The point of this issue is to let people know I'm planning to work on this myself and to ask for comments and feedback.

[edit: I'm not sure about the corrupted strings for 10.0.0-beta.2. I've definitely seen that in the past, but I've been having trouble reproducing it.]

[tannewt]

I think updating TinyUSB to the latest commit would be the best first step for this issue. Totally possible it's been fixed already.

[samblenny]

Originally, I encountered this problem last year on 9.1.something, or perhaps 9.2.something, using a Feather TFT ESP32-S3 with a MAX3421E USB host FeatherWing. At that point I got started on doing my own descriptor parsing, so it's been a while since I've tried accessing Device.manufacturer, Device.product, and so on.

Today I got out my pile of USB test devices and tried to write a reproducer for this on 10.0.0-beta.2 with a Fruit Jam rev D board. So far I haven't been able to reproduce the corrupted strings. I have gotten null values for the whole descriptor. But, that seems like kind of a different thing (not parsing) that involves missing error handling around unplug events. See #10563 (USB Host: Unplugging device can break usb.core.find()).

[edit: In the past, when I saw corrupted descriptor strings, that was in the context of running code that tried to automatically re-connect to devices that had been unplugged then plugged back in. It's possible the root cause for all of this could involve unplug error handling.]