FutureWiz
loading...
Thank you for your query. We will reply to you at the earliest.

USB Mass Storage Class - BOT

Resources >> Blogs >> USB Mass Storage Class - BOT

USB Mass Storage Class - BOT

Introduction

To gain a comprehensive understanding of the Bulk Only Transfer (BOT) Protocol, let's first understand Universal Serial Bus (USB) in brief. USB is widely recognized in the industry as a standard specification for cables, connectors, and protocols that facilitate the seamless interfacing, communication, and powering of computers, peripherals, and hubs.

In mid-1990s a consortium of companies including Compaq, DEC, IBM, Intel, Microsoft, NEC, Nortel and others developed USB with the aim of simplifying the process of connecting external devices to computers. This goal was achieved by replacing various legacy connectors, such as RS-232, mini-DIN, Game port DA-15, and External Parallel Ports, which were commonly used for connecting keyboards, printers, mice, joysticks, and removable media devices with the USB port.    


Fact: Apple has replaced its Legacy Lightning Port with the USB Type C port in their iPhone 15 models, which allows the user to charge and connect to a variety of devices, including Mac, iPad, AirPods Pro (2nd generation), external storage devices, and displays.

The USB port facilitates high-speed data transfer, providing enhanced data security and enabling seamless connections between multiple devices and hosts via hubs. It supports low power modes, allows for the tunnelling of various protocols, and offers plug-and-play functionality for external devices. Additionally, the USB port enables both intra (HOST-DEVICE) and inter (HOST-HOST) domain connections, ensuring efficient communication across different devices and systems.


USB was initially released in 1996 and has since undergone four generations: USB 1.x, USB 2.0, USB 3.x, and USB4. The following table gives a brief comparison between these generations:

USB Versions

USB 1.x

USB2.0

USB3.x

USB4.x

Year of release

USB 1.0 in January, 1996

April, 2000

USB 3.0 in November, 2008

USB4 in August, 2019

USB 1.1 in August, 1998

USB 3.1 in July, 2013

USB4 2.0 in September, 2022

USB 3.2 in September, 2017

Maximum Transfer Rates

USB 1.0 with Low Speed 1.5Mb/s

High Speed

480 Mb/s

Super Speed (Gen1)

5Gb/s

Gen 2

(Single lane 10Gb/s

Dual lane 20Gb/s)

Super Speed Plus
(Gen 2)

10Gb/s

Gen 3

(Single lane 20Gb/s

Dual lane 40Gb/s)

USB 1.1 with Full Speed 12Mb/s

Super Speed Dual Lane

10Gb/s

Gen 4

(only dual lanes Symmetric mode)

80Gb/s

Super Speed Plus Dual Lane

20Gb/s

Gen 4 (dual lanes Asymmetric mode)

120Gb/s

Features

USB 1.1 was the first to introduce legacy free PC, with extension cable

USB2.0 is backward compatible with USB1.x

USB3.2 is backward compatible with USB3.1 and USB3.0, even it can fall back to USB2.0

USB4 includes V1 with Gen 2 and Gen 3 Operations and V2 adds Gen4 Symmetric, Asymmetric and Gen T Operations

USB1.1 also has improvements of timing and power management over USB1.0

Improved and Smaller connectors like Mini USB, Micro USB Type A/B, were introduced

USB3.2 introduced Dual Lane operations which improves the bandwidth and speeds

USB4 introduced asymmetric link operations to increase the bandwidth and RSFEC encoding for better data integrity

USB1.x includes Type A and Type B ports

OTG (On the Go) connectors were introduced to connect 2 USB devices without a need of Host

USB 3 Gen1 uses 8b/10b encoding and Gen 2 uses 128b/132b encoding process for data integrity

USB4 Gen 2,3 uses 128b/132b, PAM2 encoding, and Gen 4 introduced PAM3 encoding that allows 3 level signals, called trit to transmit data instead of 2 level binary signal

Bulk Only Transfer was introduced in USB1.1

Data transfer support for Bulk, Interrupt and Isochronous endpoints was introduced

Bulk Stream endpoint was introduced in order to process multiple commands at a time

USB4 allows tunnelling of other protocols like PCIe, DP, Ethernet, USB3.x, USB2 and Gen T for allowing Gen1 operation via USB4

Power Delivery Capability

Maximum up to 2.5W (5V, 500mA)

supports 2.5W default power and introduced Battery Charging Specification (BC 1.2) power delivery increased to 7.5W (5V, 1.5A)

USB3.x supports 4.5W default with BC 1.2 supporting 7.5W, also it introduced USB Power Delivery Spec, that supports Max power up to 100W

USB4 mandates support of USB power delivery of 100W (20V, 5A) through the USB Power Delivery (USB PD) Specification

           

     Table 1 - Comparison between various USB Generations

 

Now with the basic overview of USB, let us discuss its four types of transfer:

  • Control Transfer:

It is a non-periodic and burst type of transfer, which is mainly used in the enumeration of a device/hub connected to the Host. It is used to initiate a command and to obtain a status of completion. It is a bi-directional communication i.e., control endpoint can both receive and send data packet.

  • Isochronous Transfer:

It is a periodic and synchronous type of transfer. Here, data is transferred either from Host to Device or vice-versa on a unidirectional endpoint. This type of transfer is widely used in real-time applications where data transfer is in sync with the time. If a packet is corrupted, it will not be retried but it guarantees the latency in transfer is constant. It is generally used in Visual/Audio data transfer to a Monitor/Speaker connected as a device via USB.

  • Interrupt Transfer:

In this type of transfer, a non-periodic and small amount of data is transferred either from Host to Device or vice-versa on a unidirectional endpoint. It is generally used in a Keyboard/Mouse connected as devices via USB to the host.

  • Bulk Transfer:

It is either Host to Device or vice-versa data transfer to a unidirectional endpoint, and a large amount of data is transferred in burst. Bulk Transfer uses the maximum Bandwidth allowed by that protocol. It

Let us now focus on a Data Transfer via Mass Storage Devices application. USB Device Class Definition for Mass Storage Devices, Bulk Only Transfer (BOT) was initially drafted by USB Implementers Forum on 23rd September, 1998 (v0.7), and the final revision (v1.0) came on 31st September, 1999.

The following diagram gives an overview of the environment of hardware and software used in Data Write operation on an external mass storage device by a Host:

                                                                                      

               Figure 1 – BOT Specific Environment to Write Data in Device Memory Example

The user interacts with the application through the operating system, initiating a process that involves the following steps:

• The transfer process for the selected data is initiated by the Operating System.

• The File System retrieves the address, size, and other parameters of the data vector and furnishes this information to the USB Class Driver.

• The USB Class Driver establishes a connection with the device, conducts enumeration, and prepares to transfer a bulk data set at a designated speed.

• Utilizing the USB BOT Protocol Driver, the USB Class Driver generates commands and data in fixed-sized blocks, while accessing memory through the Hardware driver (xHC).

• Subsequently, the data is transmitted to the connected device via a USB cable and is processed by the USB BOT Protocol Driver on the device's end.

• Following the host's instructions through commands, the device writes the received data to its memory at the specified location and acknowledges the successful data transfer.

Now, let us know about BOT in more detail, BOT (Bulk Only Transfer) is a single-threaded protocol, in which every transaction/command is initiated by the Host and then the device responds with a Data transfer (optional) that is followed by the status of its completion or failure. The Host waits for the status stage to be completed to initiate the next command.

As the name suggests, BOT only uses BULK IN and BULK OUT endpoints for the transfer of its 3 stages: Command, Data (Optional) & Status. Command Stage is a BULK OUT transaction, Status Stage is a BULK IN Transaction & DATA Stage can be BULK OUT for writing data into the device memory or it can be BULK IN to read data from the device memory.

Implementation

  • To execute a command, firstly Host should enumerate the attached device, by using the control endpoint.
  • While enumeration, the interface of BOT should be set in the environment by SET INTERFACE command, the value of bInterface Protocol field in device must be set as ‘h50 and must have two endpoints i.e., BULK IN and BULK OUT other than the control endpoint.
  • After completing the enumeration Host must perform certain commands to read the capabilities of the device, then it performs either a READ or WRITE operation on device’s memory
  • The device memory can be a file in which the device will store the data in a particular format, including the address and data on that address.
  • Initially, the Host generates a command as 31 bytes of BULK OUT transaction, which is called the CBW (Command Block Wrapper) and has the information of Signature value, Tag Value, Command Type, length of data to read or write, CBWCB etc.
  • The device receives this data as a BULK OUT transaction and checks the length which should be 31bytes and then looks for the signature value which should be ‘h43425355.
  • Then the device will consider this transaction to be a CBW and will extract the CBWCB (command block wrapper command block) to decode the command. The device then prepares the data (optional) for the data stage.
  • If there is a data stage according to the command then either BULK IN or BULK OUT is initiated by the Host and the data is transferred.
  • After the data stage or command stage, the device needs to send the status of the command via the STATUS stage, using a Command Status Wrapper (CSW) of 13 bytes
  • CSW contains a signature value, information of either passing or failing of command, it also contains Tag ID of the command. It is a BULK IN stage.
  • Host and device differentiate a CSW and CBW BULK transfer by their unique signature values and data length.
  • After the command stage, data stage (optional), and status stage are completed then we consider that a BOT transfer has been completed
  •  There can be a case in which the device may detect an internal error, so in this case, the device can report Host with CSW status field as STALL condition
  • In Stall condition, the Host should initiate Reset Recovery and re-initiate the command for which STALL was received.

 Figure 2 – BOT Specific Device Enumeration and Data Flow Example

Application

BOT Mass Storage Class drivers are by default present in all flavours of Windows and Linux. The application that demonstrates the BOT function driver can be to transfer data to a removable disk, like Pen-Drive, Hard disks etc. With the transfer of data, the application also performs the following services:

  • Reading capabilities, size etc. of the attached USB device
  • Write, Read, Edit, or Delete files on the simulated memory device
  • See the capacity of the SD memory card by using the disk properties function of the PC

Conclusion

There have been two advanced versions of BOT, one is Small Computer System Interface (SCSI), and the other is USB Attached SCSI Protocol (UASP). SCSI protocol is an enhancement to BOT protocol and it is used in USB system. SCSI has capability to access higher range of addresses to read and write, and also it can read and write more bytes of data at a time compared to BOT. UASP is a multi-thread protocol in which multiple commands can be initiated from the host parallelly, in UASP two more endpoints are added, BULK IN stream and BULK OUT stream, so multiple transfers can be initiated parallelly on different streams.

For any query please contact us