MSC Architecture
- Former user (Deleted)
- WES Admin
Overview
Figure - MSC Architecture shows the general architecture of a USB Host and a USB MSC Device.
On the host side, the application communicates with the MSC device by interacting with the native mass storage drivers and SCSI drivers. In compliance with the BOT specification, the host utilizes the default control endpoint to enumerate the device and the Bulk IN/OUT endpoints to communicate with the device.
SCSI Commands
The host sends SCSI commands to the device via the Command Descriptor Block (CDB). These commands set specific requests for transfer of blocks of data and status, and control information such as a device’s capacity and readiness to exchange data. The μC/USB MSC Device supports the following subset of SCSI Primary and Block Commands listed in Table - SCSI Commands.
| SCSI Command | Function |
|---|---|
| INQUIRY | Requests the device to return a structure that contains information about itself. A structure shall be returned by the device despite of the media’s readiness to respond to other commands. Refer to SCSI Primary Commands documentation for the full command description. |
| TEST UNIT READY | Requests the device to return a status to know if the device is ready to use. Refer to SCSI Primary Commands documentation for the full command description. |
| READ CAPACITY (10) READ CAPACITY (16) | Requests the device to return how many bytes a device can store. Refer to SCSI Block Commands documentation for the full command description. |
| READ (10) READ (12) READ (16) | Requests to read a block of data from the device’s storage media. Please refer to SCSI Block Commands documentation for the full command description. |
| WRITE (10) WRITE (12) WRITE (16) | Requests to write a block of data to the device’s storage media. Refer to SCSI Block Commands documentation for the full command description. |
| VERIFY (10) VERIFY (12) VERIFY (16) | Requests the device to test one or more sectors. Refer to SCSI Block Commands documentation for the full command description. |
| MODE SENSE (6) MODE SENSE (10) | Requests parameters relating to the storage media, logical unit or the device itself. Refer to SCSI Primary Commands documentation for the full command description. |
| REQUEST SENSE | Requests a structure containing sense data. Refer to SCSI Primary Commands documentation for the full command description. |
| PREVENT ALLOW MEDIA REMOVAL | Requests the device to prevent or allow users to remove the storage media from the device. Refer to SCSI Primary Commands documentation for the full command description. |
| START STOP UNIT | Requests the device to load or eject the medium. Refer to SCSI Block Commands documentation for the full command description. |
Storage Layer and Storage Medium
The storage layer shown in Figure - MSC Architecture is the interface between the MSC and the storage medium. The storage layer is responsible for initializing the storage medium, performing read / write operations on it, as well as obtaining information regarding its capacity and status. The storage medium could be:
- RAM
- SD/CF card
- NAND flash
- NOR flash
- IDE hard disk drive
The MSC can interface with three types of storage layer:
- RAM disk
- µC/FS
- Vendor-specific file system
By default, Micrium will provide a storage layer implementation (named RAMDisk) by utilizing the hardware’s platform memory as storage medium. Aside from this implementation, you have the option to use Micrium’s µC/FS or even utilize your own file system referred as vendor-specific file system storage layer. In the event you use your own file system, you will need to create a storage layer port to communicate with the storage medium. Please refer to the Porting MSC to a Storage Layer page to learn how to implement this storage layer.
Figure - µC/FS Storage layer shows how the µC/FS storage layer interfaces with µC/FS.
µC/FS storage layer implementation has two main characteristics:
- High-level lock mechanism.
- Insertion/removal detection of removable media.
The high-level lock mechanism protects the storage medium from concurrent accesses that could occur between a host computer and an embedded µC/FS application. On one hand, if a mass storage device is connected to a host computer and the storage medium is available, the host computer has the exclusive control of the storage medium. No embedded µC/FS application can access the storage medium. The µC/FS application will wait until the lock has been released. The lock is released upon device disconnection from the host or by a software eject done on the medium from the host side. On the other hand, if a µC/FS application has already the lock on the storage medium, upon device connection, the host won’t have access. Each time the host requests the storage medium presence status, the mass storage device will indicate that the medium is not present. This status is returned as long as µC/FS application holds the lock. As soon as the lock is released, the host takes it and no more µC/FS operations on the storage medium are possible.
µC/FS storage layer is able to detect the insertion or removal of a removable media such as SD card. A task is used to detect the insertion or removal. The task checks periodically the presence or absence of a removable media. When the mass storage device is connected and the removable media is not present, the mass storage device indicates to the host that the storage medium is not present. As soon as the removable media is inserted in its slot, the task in µC/FS storage layer updates the removable media presence status. Next time the host requests the presence status, the mass storage device returns a good status and the host can access the content of the removable media. The opposite reasoning applies to media removal. If your product uses only fixed media, the task in µC/FS storage layer can be disabled. You can also configure the task’s period. Refer to the General Configuration section for more details about µC/FS storage layer configuration.
Multiple Logical Units
The MSC class supports multiple logical units. A logical unit designates usually an entire media type or a partition within the same media type. Figure - Example of Logical Units Configurations illustrates the different multiple logical units configurations supported.
(1) Configuration #1 is an example of single logical unit. The whole RAM region represents one unique logical unit. This configuration is a typical example of USB memory sticks. When the device is connected to a host, this one will display a media icon.
(2) Configuration #2 is an example of multiple logical units within the same media. Each logical unit could be seen as a partition. This configuration is a typical example of USB external hard drive. When the device is connected to the host, this one will display three media icons.
(3) Configuration #3 is an example of multiple logical units of different type. This configuration a a typical example of multi-card reader.
Configurations #1 and #2 are supported by the RAMDisk storage layer. Configurations #1 and #3 are supported by the µC/FS storage layer. The configuration #2 is currently not supported by the µC/FS storage layer.
Each logical unit is added to the MSC at initialization. Refer to the Class Instance Configuration section for more details about the multiple logical units initialization and to the MSC Host Application section for a Windows example of multiple logical units.