Observed USB Mass Storage Target Deviations from the Published Specification 03 July 2001 Matthew Dharm Revision 1.0 This document is intended to record some of the "unusual" behavior I have observed from various devices. Some of these devices are in my possession, while others are not. The information in this document should be considered public domain, as these observations can be made by the end-user consumer and were not made on prototype hardware or other hardware protected by an NDA. Device fails to report media change ----------------------------------- This has been observed with some Sony MemoryStick products (and their embedded equivalents in various cameras, et al). The device detaches when media is not inserted, but never generates a UNIT_ATTENTION to indicate media change, in violation of the SubClass code specifications. Device reports bogus data in ANSI SCSI revision ----------------------------------------------- By bogus, I mean useless. This is arguable for many devices, but anything that reports "Transparent SCSI" should be reporting 0x01 or 0x02 here -- reporting 0x0 is like saying "I'm SCSI, but I'm not." Device does not implement 6-byte commands ----------------------------------------- Apparently, Windows and MacOS only use 10-byte READ/WRITE/MODE_SENSE commands. If you're claiming "Transparent SCSI", then you should support the mandatory 6-byte command also. SCSI I and II (and I believe even III) require these commands to be implemented. This is especially difficult to handle in host software in the case of MODE_SENSE/SELECT. Device fails to implement required mode pages --------------------------------------------- I think the title says it all. Some devices don't implement the required mode pages -- they only implement what Windows/MacOS is likely to request. Tho most operating systems are only interested in the header data (write-protect bit is there), some page code must be used in the MODE_SENSE command. Sometimes (but more rarely), the code for "all pages" does not work. Device does Bad Things(tm) when it gets a GET_STATUS after CLEAR_HALT --------------------------------------------------------------------- Mass storage is the big user of the STALL condition, it seems. Windows, when clearing a stall, only sends the CLEAR_HALT command, and presumes that the stall has cleared. Some devices actually choke if the CLEAR_HALT is followed by a GET_STATUS (used to determine if the STALL is persistant or not). Device does Bad Things(tm) when CBWDataTransferLength disagrees with the command contained in the CBW ------------------------------------------------------------------------ I've covered this in e-mails on the usb-mass list, but basically the title says it all -- if the transfer length as encoded in the two locations disagrees with each other, bad things go on. This is especially difficult to deal with, as the same command code means different things to different types of devices -- i.e. SEND is the same code as WRITE_6. This creates another place where "Transparent SCSI" breaks down. CBI Interrupts badly timed -------------------------- I've seen CBI devices fire the interrupt before the completion of the data transfer. In some cases, I've seen it fire before the data stage transfer begins. This makes synchronization almost impossible. Interrupt endpoint On Crack(tm) ------------------------------- Note to non-Americans: "Crack" is the street name for a very powerful and addictive illegal drug, similar to cocaine. I've seen devices (more than one!) where the interrupt endpoint is _constantly_ firing. Usually, the data is complete garbage. When a command is issued, one of the interrupts actually does have useful data -- finding it is impossible, however. My best guess is that popular OSes only poll the interrupt endpoint when a command is pending, but that's just a guess. Device takes very long to become ready -------------------------------------- Certain digital cameras take a long time to respond to commands. While the device is fully enumerated, the end of the camera that actually responds to a command (i.e. INQUIRY) isn't ready for a few seconds -- any command sent during this time is failed in various inconsitent ways. Unfortunatley, REQUEST_SENSE also fails during this time. Workaround: Fake the inquiry data while probing and hope for the best. Wrong Signature in CSW ---------------------- The title says it all: The CSW from a device contains the wrong 4-byte signature. Lord knows how that passed Q/A. Device doesn't implement GetMaxLUN ---------------------------------- Of course, this only applies to BBB devices. It wouldn't be a real problem, but some of these devices are multi-LUN devices Bogus data in INQUIRY response ------------------------------ I'm guessing that this probably applies to the data response from other commands besides INQUIRY, but this is a good starting point: Certain devices return 0x0 in various fields improperly -- most notably, the length of the INQUIRY data, where 0x24 is the minimum legal length. Failure to retrieve unusual data lengths for some commands ---------------------------------------------------------- Several devices fail if you attempt to get less then the 8-byte header of a MODE_SENSE command -- even if the command is properly formatted by the most stringent standards. That is, all length fields indicate 2 bytes, and only 2-bytes of IN tokens are sent... the best devices in this category report Phase Error in the CSW -- some just die. The reasoning behind this is to get the length of the MODE_SENSE data, then allocate a full-size buffer for the information, and the get all of the data into the exact-sized buffer. It should be legal, but some devices can't do this -- CD-ROMs are the worst offenders here, but that's just anecodtal evidence. CB (no I) devices have invisible status --------------------------------------- Because of the various "may"s in the CB/I specification, it's legal to build a device which accepts all commands/data given to it, and fails every command without actually informing the host in any way. Naturally, I think the various "may" clauses were meant to denote "choose one of these ways", but it wound up meaning "do this or not" for various ways. As a result, all CB devices must be sent a REQUEST_SENSE immediatly after every command to determine if the command worked. Needless to say, this is _bad_ for bandwith. Device sends 2-byte IRQ data with bogus first byte -------------------------------------------------- Title says it all -- according to spec, a CBI device sends 2 bytes on every interrupt, and byte[0] should == 0x0. It doesn't always. Device sends more/less than 2-bytes on IRQ ------------------------------------------ Another title which says it all -- a CBI device which sometimes sends 1 byte and sometimes 3 or 4 bytes on the IRQ endpoint. BBB Device reports FAILED when just short ----------------------------------------- Some BBB devices report status 0x01 (Failed) in the CSW when the device returns less than the requested data, even when this is legal. Consider the case of variable-length data sets (i.e. INQUIRY response) to see when this can occur. Device answers to every LUN --------------------------- Some devices respond to all LUNs, even if it's a single-LUN device. There are multiple ways of indicating "LUN not supported" -- fail the command with apropriate ASC/ASCQ, or certain bits in the INQUIRY stream. Some devices do neither. Device fails to implemnt START_STOP ----------------------------------- I list this separately from the 6 vs 10 byte command item earlier in this document, as in the other case, equivalent function was available via other commands. That is not the case with this command. While many devices don't need it (or just ignore it), some crash if the host sends it. Device reports invalid SubClass/Protocol codes ---------------------------------------------- Several devices report Class == 0x08 (stor.) with invalid SubClass/Protocl codes (usually 0xFF). I'm _guessing_ that this happens because popular OSes treat all devices the same, but that's just a guess. Bogus serial numbers -------------------- I've seen devices with no serial number, non-number serial numbers, invalid characters in the serial number (dashes seem popular), dynamic serial numbers, etc. All of these cause headaches.