0
\$\begingroup\$

I am developing an xHCI host that connects to a type A downstream connector via a HS USB 2.0 connection. I am testing it using a generic HS flash drive. The flash drive sometimes responds to the DEVICE Descriptor request with idVendor = 0xabcd and idProduct = 0x1234, and to the SCSI Inquiry command with VendorID = "General" and ProductID = "UDisk". When the flash drive responds this way, it works fine. However, at other times it responds with idVendor = 0x1e3d, idProduct = 0x198a and SCSI Inquiry response Vendor = "ChipsBnk" and Product = "Flash Disk". In this case, the SCSI Test Unit Ready command always fails.

I have noticed that this alternate "ChipsBnk" "Flash Disk" configuration is only seen when connecting to my board and not consistently. When I connect the flash drive to Windows, the enumeration process never shows the "ChipsBnk" "Flash Disk" response and it always works as expected.

I have also observed this behavior on a Sandisk 128G drive, which usually responds to SCSI Inquiry with vendor = "USB" and product = "SanDisk 3.1Gen1", but sometimes it responds with vendor = "SanDisk" and product = "Anisha".

What could cause the same flash drive to respond with different vendor id and product id values? I am curious if it is a common occurrence for these drives to switch to a firmware mode due to some special signaling sequence that I might be inadvertently triggering.

\$\endgroup\$
4
  • \$\begingroup\$ maybe a fake drive \$\endgroup\$
    – jsotola
    Commented Feb 6, 2023 at 22:50
  • \$\begingroup\$ Sounds like something is flawed on your host design. Could be many issues. Did you follow all design notes for the host-IC? Capacity on D+ / D- is ok? Rise-time of power to device ok? Are there failed identification attempts before it finally makes it? A bit more detail could help. \$\endgroup\$
    – datenheim
    Commented Feb 7, 2023 at 7:36
  • \$\begingroup\$ Thanks, @datenheim these are good things for me to check and I think there may be an issue with the VBUS. I was mainly wondering if anyone else knew if it is common for these flash drives to have some non-standard mode where they will identify themselves differently since I'm kind of new to USB but I've seen a couple of drives do this multiple personality thing now. \$\endgroup\$
    – Bill Morgan
    Commented Feb 7, 2023 at 16:12
  • \$\begingroup\$ That is true, some sticks allow some kind of "firmware upgrade" or similar things, whatever it is used for. Often it is undocumented. But still - if it does not happen on your PC, it should not hapoen on your host. \$\endgroup\$
    – datenheim
    Commented Feb 7, 2023 at 17:25

1 Answer 1

Reset to default
1
\$\begingroup\$

VID, PID and all other descriptor information is usually hardcoded in the USB-to-Flash interface chip. Therefore, with interface operating correctly, this information must read always the same. If it is different and flaky, it means that your host protocol is unstable and violates something, ether at electrical (timing) or logical level. You would need to use a USB protocol analyzer to narrow the problem down. Sometimes the host failure to keep connect debouncing time of 100+ ms (or reset delay of 10ms) would cause goofy responses, check if you are not trying to get_decriptor too early.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.