A mass storage device does not require any special USB driver, since the support is already built into the OS. The technology is so mature, that I am not interested in them at all. However I realize that the mature technology is very useful in some special devices when I evaluated a STM32 board.

When I plugged the EV board into my PC, the OS prompted me that a mass storage device was found. At first I was quite confused. I supposed that it should be a prompt of asking for device driver. The new disk driver contains several hyper links, which point to the document, datasheet and the device driver. The memory size of this new disk is 256MB, but you can never copy or delete any files. Obviously this mass storage device is emulated by the STM103 Cortex-M3(see the Datasheet) on the EV board. It is a feature to demonstrate the capability of M3. It is a smart idea, the board first leads the user to download the driver, and then the user can install the driver and start to use it.

Check out the attached pictures of the ACCESSstick, which is a biometrically secure USB device with all of the relevant enterprise clients pre-installed that users carry with them. For more information, please check the datasheet in the read more section. This device can offer single sign-on, session data storage, and strong biometrical authentication for the enterprise users.

However, I knew some people are using this technique to sell the fake USB sticks in the market. These USB sticks are marked in a huge size as 320GB memory. It is ridiculous to see a 320GB USB stick available at only 12USD.

Let us come back and concentrate on the implementation of a USB mass storage device. I will cover the embedded USB host in another blog.

A USB mass storage device implementation is relatively easy and widely available. You can find many reference designs from NXP, Cypress, Microchip, Atmel, and Freescale.

The USB mass storage does not require any particular file system to be used on the devices. They are independent of OS, although most of them are formatted as FAT16/32. Like other low level interfaces, the SCSI command set is used in USB mass storage device providing a simple interface to access the sectors of data. Because of the SCSI interface, the Linux OS always considers it as a SCSI driver.

The embedded microcontroller in a mass storage device could be as simple as an 80C51 or a PIC, since it only translates the low level command and access the flash memory accordingly. The embedded controller doesn’t have to integrate too much intelligence at all. As a result, the overall speed of a flash driver is quite fast. The new multi-functional devices integrate the mass storage independently so the users can access the memory directly in a fast speed. These devices usually work in different modes, working mode and storage mode. The device controller will act a simple flash controller in the storage mode. It is quite easy to verify, when I plug my K750 to a PC, I can not access the content via mobile phone UI any more.

Alternatively, an embedded controller can access the flash devices locally and transfer the files over USB. Because the embedded controller has to implement the file system, low level flash driver, wear leveling algorithm, and use a proprietary USB protocol. The overall file transfer speed is relatively slow on an embedded system. The pocket PC is a good example for such system structure.

If you plan to develop an embedded Linux project, you have to check which approach is used in the design. By default, the Linux is working as a USB host, not a USB device. If you want your system to act as a device, please visit Linux USB gadget API Framework.

Read More

ACCESSstick datasheet from Accario, Critrix ready
http://www.accessstick.com/assets/pdf/AS-accario-citrix.pdf

STM32 USB Mass Storage Device Example
http://www.keil.com/download/docs/362.asp

The Mass Storage Page of LVR LLC.
http://www.lvr.com/mass_storage.htm

Linux-USB Gadget API Framework
http://www.linux-usb.org/gadget/