General USB Device Classes

• CDC, HID, and MSC cover the most common usages. 
•  A device containing more than one interface is said to be a composite USB device such as two USB interfaces: CDC and MSC. from http://fiona.dmcs.pl/~pzajac/pliki/SMwZW/Examples_Guide_MSP430_USB.pdf   

IAR and CCS are both available in free, code-size-limited versions (8K and 16K, respectively, of object code). Simple applications having no MSC interface can be run on both free versions. Applications having an MSC interface (and thus a larger application to implement the storage volume) generally don’t fit under 8K; for this reason, the free IAR Kickstart won’t build them. Instead, the free version of CCS can be used, or a licensed version of either environment.

The API is the foundation of the MSP430 USB Developers Package. It supports three of the most common USB device classes: • Communications Device Class (CDC): (ACM class) Results in a virtual COM port on the host • Human Interface Device class (HID): The MSP430 USB Developers Package defines four subtypes: – Datapipe (an unformatted general-purpose interface resembling CDC) – Mouse – Keyboard – Custom • Mass Storage Class (MSC): When the host sees an MSC interface, it begins mounting a storage volume from it.

• ...The MSP430 MSC device, when attached to a USB host, displays as a storage volume on the operating system. The MSC protocol receives and executes SCSI commands from the host and uses the SCSI transparent command set for its use. All handling of SCSI commands is performed automatically by the MSP430 USB API stack with some support by the application.
• A primary purpose of the MSC protocol is to receive and execute SCSI commands from the host. SCSI (Small Computer System Interface, pronounced “scuzzy”) is a set of specifications covering various levels of protocol, including a physical cable interface. One of the SCSI command sets – the SCSI transparent command set – has been adopted for use with the MSC protocol. This is the command set supported by this API.
• When the host sends a SCSI command over the MSC protocol, it designates the LUN for which the command is intended. If the command reads/writes data, it also includes the LBA being accessed and the number of sequential blocks requested. Since the API must rely on the application to make the file system access calls when a SCSI read or write command is received, the API makes the SCSI command’s LUN, initial LBA, and number of requested blocks available to the application. Only one SCSI command at a time can be handled by an MSC interface. This means that if a command is received for LUN 0, it must be handled in full before a command can be received for LUN 1. For this reason, only a single interchange buffer is needed for the interface (or two, if double-buffering is used). (The current API version only supports single-buffering.) 
• The MSC API automatically handles all SCSI commands required to function with the target host operating systems, based on information it receives from the application. The list of SCSI commands includes: • INQUIRY • REQUEST SENSE • TEST UNIT READY • READ • WRITE • READ CAPACITY • MODE SENSE • REPORT LUNS 
• http://uglyduck.ath.cx/PDF/TexasInstruments/MSP430/usblib430/Programmers_Guide_MSP430_USB_API.pdf
• Every USB application with an MSC interface must call this function regularly to check for any SCSI commands received from the host. The USB MSC interface is essentially a carrier for the same SCSI commands used with many non-USB storage devices that are commonly used with computers. In other words, the interface is essentially "SCSI-over-USB".
• http://datasheet.octopart.com/MSP-EXP430F5529LP-Texas-Instruments-datasheet-17794772.pdf

• SCSI

  Hard drives, flash drives, and other USB mass-storage devices support commands in the SCSI Primary Command (SPC) Set and SCSI Block Command (SBC) Set fromwww.t10.org (INCITS Technical Committee T10).
•  http://pollos-blog.blogspot.tw/2014/10/usb-mass-storage-class.html --> Command structure