Removable electronic device and method thereof

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/607,344, filed September 7, 2004, which is herein incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates generally to a removable electronic device and, more particularly, to a removable memory card standard and method thereof.

A memory card is commonly known as a small portable package containing digital memory, such as an array of non-volatile memories, such as flash memories, EPROMs, or EEPROMs (electrically erasable and programmable read only memory). Memory cards have gain popularity as a device for storing a substantial amount of bytes of data from personal computers, notebook computers, personal electronic assistants, cellular telephones, cameras and other electronic devices that support removable data storage.

In general, a memory card includes exposed electrical contacts on its surface to allow easy connection to and removal from a receptacle of a host electronic system or device, particularly portable devices. A number of standards for a memory card have been implemented, including the MultiMedia Card ("MMC") by the MultiMedia Card Association ("MMCA") of Cupertino, California. An MMC is a compact, removable memory card for storing and retrieving digital information in small, low power devices. MMC has been used in many mobile electronic applications, such as music players, mobile phones, personal digital assistants (PDAs), digital cameras, voice recorders, and GPS navigation devices. The MMCA developed and regulated its open industry standards, and also defined all types of MMCs as an industry standard across multiple host platforms and markets. The physical and electrical specifications for the MMC are given in "The MultiMediaCard System Specification" that is updated and published from time-to-time by the MMCA.

Another known standard for a removable memory card, although not limited to memory storage, is the Universal Serial Bus ("USB"). USB is a high-speed serial bus that supports devices such as printers, keyboards, scanners, pointing devices, and PDAs. USB has become a standard within the computer industry as this protocol affords networking of multiple devices with minimal connections and increased user friendliness. USB is currently defined by the Universal Serial Bus Specification, written and controlled by USB Implementers Forum, Inc., a non-profit corporation founded by a group of companies that developed the USB specification. The specification covers all aspects of USB operations, including electrical, mechanical, and communications characteristics and specifications. One significant feature of the USB is that it allows a peripheral device to store information about itself, and to provide such information upon request by the host. This obviates the need for the host, be it a computer, operating system, or application program, to maintain this information for many different devices. Instead, the device itself stores and provides the information.

In the evolution of memory cards, it is desirable to have memory cards that consumes low power and provides higher speed for accessing, while still retaining backward compatibility with existing protocols such as the MMC and USB specifications.

BRIEF SUMMARY OF THE INVENTION

A novel removable memory card standard is disclosed. The standard of the present invention includes both detection schemes and hardware interface compatibility requirements. Furthermore, the novel standard is backward compatible with the MMC and USB applications.

In accordance with an embodiment of the present invention, there is provided a removable electronic device that comprises a detector for detecting a mode of operation to distinguish among a multimedia card (MMC) compatible mode, a universal serial bus (USB) compatible mode, and a Mu mode, a wrapper for converting data for transfer between the USB compatible mode and the Mu mode, a USB physical layer circuit for transferring data compatible with the USB compatible mode, a USB compatible device controller for controlling data transfer in the USB compatible mode, and an MMC compatible device controller for controlling data transfer in the MMC compatible mode.

Further in accordance with the present invention, there is provided a removable electronic device having an application module for transferring data to or from a host, the device comprising a detector for detecting a mode of operation among a plurality of modes of operations, including at least a Mu mode and a first mode of operations, a wrapper for converting the data to transfer between the first mode and the Mu mode, a circuit to transfer the data compatible with the first mode of operation, and a compatible device controller to control data transfer in the first mode.

Also in accordance with the present invention, there is provided a method for a removable electronic device to detect a mode of operation to distinguish among a multimedia card (MMC) compatible mode, a universal serial bus (USB) compatible mode and a Mu mode, the method comprising determining whether a power source voltage is greater than a predetermined voltage level, assessing the USB compatible mode when the power source voltage is greater than the predetermined voltage level, receiving a command signal sent from a host, determining whether the command signal corresponds to a Mu format, and assessing the Mu mode operation when the command signal corresponds to the Mu format or otherwise assessing the MMC compatible mode.

Still in accordance with the present invention, there is provided a method for a removable electronic device to detect a mode of operation to distinguish between a multimedia card (MMC) compatible mode and a Mu mode, the method comprising receiving a command signal sent from a host, determining whether the command signal corresponds to a Mu format, and assessing the Mu mode operation when the command signal corresponds to the Mu format or otherwise assessing the MMC compatible mode.

Yet still in accordance with the present invention, there is provided a method for a device that receives a removable electronic device to detect a mode of operation between at least a multimedia card (MMC) compatible mode and a Mu mode, the method comprising sending a command signal corresponding to a Mu format after receiving the removable electronic device, detecting whether the removable electronic device responds to the command signal, assessing that the mode of operation is the MMC compatible mode if the removable electronic device does not respond to the command signal, and providing a Mu interface if the removable electronic device responds to the command signal.

Further in accordance with the present invention, there is provided a method for a device that receives a removable electronic device to detect a Mu mode of operation, the method comprising receiving a removable electronic device, sending a command signal to corresponding to a Mu format to the removable electronic device, detecting whether the removable electronic device responds to the command signal, and providing a Mu interface after the removable electronic device responds to the command signal.

Still in accordance with the present invention, there is provided a method for a removable electronic device to detect a mode of operation to distinguish between a first mode of operation and a Mu mode of operation, the method comprising receiving a command signal sent from a host, determining whether the command signal corresponds to a Mu format, and assessing the Mu mode of operation when the command signal corresponds to the Mu format or otherwise assessing the first mode of operation.

Yet still in accordance with the present invention, there is provided a method for a device that receives a removable electronic device to detect a mode of operation between a first mode of operation and a Mu mode of operation, the method comprising sending a command signal corresponding to a Mu format after receiving the removable electronic device, detecting whether the removable electronic device responds to the command signal, assessing that the mode of operation is the first mode of operation if the removable electronic device does not respond to the command signal, and providing a Mu interface if the removable electronic device responds to the command signal.

Additional features and advantages of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The features and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one embodiment of the present invention and together with the description, serves to explain the principles of the invention.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments which are presently preferred. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.

In the drawings:

Figs. 1A, 1B and 1C are functional block diagrams of the general applications of a memory card in accordance with one embodiment of the present invention;;

Fig. 2 is a flow diagram of a method for detecting a mode of operation in accordance with one embodiment of the present invention;

Fig. 3 is another flow diagram of a method for detecting a mode of operation in accordance with one embodiment of the present invention;

Fig. 4A is a proposed pin assignment chart of a removable electronic device in accordance with one embodiment of the present invention;

Fig. 4B is a proposed pin assignment chart of a removable electronic device in accordance with another embodiment of the present invention;

Fig. 5 is a diagram of a removable electronic device in accordance with one embodiment of the present invention; and

Figs. 6A and 6B show exemplary electronic devices in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In this detailed description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of embodiments of the present invention. One skilled in the art will appreciate, however, that embodiments of the present invention may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form. Furthermore, one skilled in the art can readily appreciate that the specific sequences in which methods are presented and performed are illustrative and it is contemplated that the sequences can be varied and still remain within the spirit and scope of embodiments of the present invention.

Figs. 1A, 1B and 1C are functional block diagrams of general applications of a removable electronic device 30 in accordance with one embodiment of the present invention. Electronic device 30, tentatively named the "Mu Card," which is able to support modes of operations compatible with USB and at least one of MMC, CF (compact flash), SM (smart media) and SD (security digital) applications. For example, the USB compatible mode includes USB 2.0 application, and the MMC compatible mode includes one of MMC 4.0 or MMC SPI (serial-peripheral interface) applications. For the purpose of simplicity, only the MMC compatible mode is illustrated in the following embodiments. Skilled persons in the art will understand that the present invention is equally applicable to the CF, SM and SD modes.

Electronic device 30 includes a 1-, 4-, 8- or 16-bit interface, and provides low voltage support of 5V/3.3V/1.8V, with zero power consumption during standby. In addition, electronic device 30 is able to support a wide bandwidth from approximately 50KB/s to 120MB/s. In contrast, MMC 4.0 supports 1-, 4- or 8-bit data transfer at a maximum speed of 52 MB/sec, and USB 2.0 supports data transfer at a maximum speed of 60 MB/sec. Consequently, electronic device 30 provides high-speed applications while retaining backward compatibility at least with regard to USB, MMC and MMC SPI applications.

Fig. 1A is a functional block diagram of electronic device 30 operating in a USB mode. Referring to Fig. 1A, electronic device 30 includes an interface (IF) mode detector 32, a multi-media card (MMC) device controller 34, a wrapper 35, a universal serial bus (USB) physical layer (PHY) circuit 36, a USB device controller 37, and an application module 38. IF mode detector 32 detects a mode of operation to distinguish among an MMC mode, a USB mode or a Mu mode when electronic device 30 is inserted into a host 40. Host 40, for example, a notebook, a personal computer (PC), a cell phone, a tablet PC, a PDA or a DV/DSC, may include a card reader (not shown) for receiving electronic device 30. In the present embodiment, IF mode detector 32 detects whether a host 40, to which electronic device 30 is connected, is in compliance with the USB specifications. USB device controller 37 controls data transfer over a common bus 42 between host 40 and application module 38 via USB PHY circuit 36. Application module 38 functions to serve as a memory storage or an input/output (I/O) interface, depending on the operation mode detected.

Fig. 1B is a functional block diagram of electronic device 30 operating in a Mu mode. Referring to Fig. 1B, IF mode detector 32 detects that a host 40, to which electronic device 30 is connected, is in compliance with the Mu specifications. USB device controller 37 controls data transfer between host 40 and application module 38 via wrapper 35. Wrapper 35, which wraps a call to a function or program inside another function or program, functions to convert 16-bit data into serial data recognizable by USB device controller 37, or vice versa. As such, wrapper 35 functions to bridge between a Mu bus and a UTMI (USB 2.0 Transceiver Macrocell Interface) bus. UTMI, which has been developed to define the interface specifications of the physical layer circuits and part of the logical layer circuits of the USB 2.0, enables a data transfer rate of 480 Mbps in high speed (HS) mode, which is significantly higher than that of the USB 1.1, while maintaining backward compatibility with the USB 1.1 standard.

Fig. 1C is a functional block diagram of electronic device 30 operating in an MMC mode. Referring to Fig. 1C, IF mode detector 32 detects that a host 40, to which electronic device 30 is connected, is in compliance with the MMC specifications. MMC device controller 34 controls data transfer between host 40 and application module 38. The MMC application includes one of MMC 4.0, a 1-, 4- or 8-bit interface, or MMC SPI, a 1-bit interface.

Fig. 2 is a flow diagram of a method for detecting a mode of operation in accordance with one embodiment of the present invention. Referring to Fig. 2, on the device side, host 40 to which electronic device 30 is connected is turned on at step 50. The power source voltage, VDD, for host 40 is detected at step 52 to determine whether the VDD is equal to or greater than a voltage level a USB application requires. Normally, a USB application is operated at a voltage level ranging from approximately 4.5V (volts) to 5.5V, while an MMC or an Mu application is operated at a voltage level of approximately 1.8V or 3.3V. In one embodiment, if the VDD level for host 40 is equal to or greater than 4.4V, a determination is made at step 54 that the mode of operation is USB 2.0. If the VDD level for host 40 is smaller than 4.4V, a determination is made that the mode of operation is either a Mu application or an MMC application.

Next, a determination is made at step 56 whether a command signal CMD0 sent from host 40 is received by electronic device 30. Detection of the command signal CMD0 is performed within a predetermined time period at step 58. If the predetermined time expires, host 40 is turned off, or "timed out" to save power at step 60. If the predetermined time does not expire, the detection of the command signal continues. When a command signal is received, a determination is made at step 62 whether the command signal indicates a Mu application. If the command signal is not a Mu command signal, a determination is made at step 64 that the mode of operation is an MMC application. If the command signal is determined to be a Mu command signal, electronic device 30 responds to host 40 that the mode of operation is a Mu application at step 66. Electronic device 30 then waits for a predetermined time, for example, 8 clocks, at step 68 for synchronization. Generally, the clock rate depends on the speed of host and system clocks. Electronic device 30 then switches at step 70 to a Mu interface for a Mu application at step 72.

Fig. 3 is another flow diagram of a method for detecting a mode of operation in accordance with one embodiment of the present invention. Referring to Fig. 3, at the host side, host 40 sends a Mu command signal Mu CMD0 to electronic device 30 at step 80. If electronic device 30 at step 82 does not send a response signal, host 40 sends an MMC command signal MMC CMD0 at step 84, indicating that the mode of operation is the MMC application at step 86. If electronic device 30 at step 82 replies with a Mu response signal, host 40 sends a predetermined number of clocks, for example, 8 clocks, for synchronization at step 88. Electronic device 30 switches at step 90 to the Mu mode. At step 92, electronic device 30 may optionally send a signal to host 40, indicating that a Mu interface is ready.

By way of example, the command signals MMC CMD0 and Mu CMD0 are defined in a 6-byte format as "40h, 00h, 00h, 00h, 00h, 95h" and "40h, 4Dh, 55h, BFh, B2h, AAh," respectively. Furthermore, the Mu response signal is defined in a 6-byte format as "19h [4-byte operating parameters] FFh."

Fig. 4A is a proposed pin assignment chart of a removable electronic device in accordance with one embodiment of the present invention. Referring to Fig. 4A, all of the pins at the device side are kept as HiZ (high impedance) state until a mode of operation between a host and the removable electronic device is determined. The first pin of the removable electronic device for the MMC 4.0 mode, i.e., DAT 3, is defined to switch the MMC 4.0 mode to the MMC SPI mode, which has been defined in the MMC Specification. The second pin for the Mu interface mode, i.e., DAT 8, is used to identify that the MMC mode or Mu interface mode is selected. The fourteenth and fifteenth pins for the USB mode, i.e., D+ and D-, are a pair of data signals, which may be used to determine whether the USB mode is selected. The pair of data signals (D+, D-) is a complementary pair in which one is at a high level when the other is at a low level. Pins 18, 19 and 20 are reserved for SIMM (single in-line memory module) card applications. Thus, the removable electronic device of the present invention is able to support MMC compatible, USB compatible and Mu-interface applications, and simultaneously retains the flexibility of working for the SIMM applications.

An exemplary interface protocol of the present invention is described as follows:

1. SYNC FIELD <ol id="ol0001" ol-style=""><li>(1) 1-bit: DAT = 0b</li><li>(2) 4-bit: DAT[3:0] = xxx0b</li><li>(3) 8-bit: DAT[7:0] = xxxxxxx0b</li><li>(4) 16-bit: DAT[15:0] = xxxxxxxxxxxxxxx0b</li></ol> Where "x" refers to a condition that is not relevant for the protocol.

2. PID FIELD <ol id="ol0002" compact="compact" ol-style=""><li>(1) 1-bit: LSB first <maths id="math0001" num=""><math display="block"><mrow><mi mathvariant="normal">DAT</mi><mo>=</mo><mi mathvariant="normal">PID</mi><mrow><mo>[</mo><mn>0</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">PID</mi><mrow><mo>[</mo><mn>1</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">PID</mi><mrow><mo>[</mo><mn>2</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">PID</mi><mrow><mo>[</mo><mn>3</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">nPID</mi><mrow><mo>[</mo><mn>0</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">nPID</mi><mrow><mo>[</mo><mn>1</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">nPID</mi><mrow><mo>[</mo><mn>2</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow><mi mathvariant="normal">nPID</mi><mrow><mo>[</mo><mn>3</mn><mo>]</mo><mi mathvariant="normal"> </mi></mrow></mrow></math><img file="EP1632864A2_D0001.tif" /></maths></li><li>(2) 4-bit: <maths id="math0002" num=""><math display="block"><mrow><mi mathvariant="normal">DAT</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>=</mo><mi mathvariant="normal">PID</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mi mathvariant="normal"> nPID</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow></mrow></math><img file="EP1632864A2_D0002.tif" /></maths></li><li>(3) 8-bit: <maths id="math0003" num=""><math display="block"><mrow><mi mathvariant="normal">DAT</mi><mrow><mo>[</mo><mn>7</mn><mo>:</mo><mn>4</mn><mo>]</mo></mrow><mo>=</mo><mi mathvariant="normal">inverted of PID</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow></mrow></math><img file="EP1632864A2_D0003.tif" /></maths><maths id="math0004" num=""><math display="block"><mrow><mi mathvariant="normal">DAT</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>=</mo><mi mathvariant="normal">PID</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow></mrow></math><img file="EP1632864A2_D0004.tif" /></maths></li></ol> Where "nPID" refers to an inverted signal of PID. The PID Data transaction is protected by the inverted mirror Data of PID and nPID. The controller in both the host and device sides should verify the validity of the PID. PID Codes are defined in Table 1 given below. <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1 PID Codes</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="21mm" colsep="1" /><colspec colnum="2" colname="col2" colwidth="21mm" colsep="1" /><colspec colnum="3" colname="col3" colwidth="21mm" colsep="1" /><colspec colnum="4" colname="col4" colwidth="104mm" colsep="1" /><thead><row><entry namest="col1" nameend="col1" align="left" valign="top"><b>PID Type</b></entry><entry namest="col2" nameend="col2" align="left" valign="top"><b>PID Name</b></entry><entry namest="col3" nameend="col3" align="center" valign="top"><b>PID&lt;3:0&gt;</b>*</entry><entry namest="col4" nameend="col4" align="center" valign="top"><b>Description</b></entry></row></thead><tbody><row rowsep="0"><entry namest="col1" nameend="col1" morerows="3" rowsep="1" align="left" valign="top">Token</entry><entry namest="col2" nameend="col2" align="left" valign="top">OUT</entry><entry namest="col3" nameend="col3" align="center" valign="top">0001B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Address + endpoint number in host-to-function transaction</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">IN</entry><entry namest="col3" nameend="col3" align="center" valign="top">1001B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Address + endpoint number in function-to-host transaction</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">SOF</entry><entry namest="col3" nameend="col3" align="center" valign="top">0101B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Start-of-Frame marker and frame number</entry></row><row><entry namest="col2" nameend="col2" align="left" valign="top">SETUP</entry><entry namest="col3" nameend="col3" align="center" valign="top">1101B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Address + endpoint number in host-to-function transaction for SETUP to a control pipe</entry></row><row rowsep="0"><entry namest="col1" nameend="col1" morerows="3" rowsep="1" align="left" valign="top">Data</entry><entry namest="col2" nameend="col2" align="left" valign="top">DATA0</entry><entry namest="col3" nameend="col3" align="center" valign="top">0011B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Data packet PID even</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">DATA1</entry><entry namest="col3" nameend="col3" align="center" valign="top">1011B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Data packet PID odd</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">DATA2</entry><entry namest="col3" nameend="col3" align="center" valign="top">0111B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Data packet PID high-speed, high bandwidth isochronous transaction in a microframe (see Section 5.9.2 for more information)</entry></row><row><entry namest="col2" nameend="col2" align="left" valign="top">MDATA</entry><entry namest="col3" nameend="col3" align="center" valign="top">1111B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Data packet PID high-speed for split and high bandwidth isochronous transactions (see Sections 5.9.2.11.20. and 11.21 for more information)</entry></row><row rowsep="0"><entry namest="col1" nameend="col1" morerows="3" rowsep="1" align="left" valign="top">Handshake</entry><entry namest="col2" nameend="col2" align="left" valign="top">ACK</entry><entry namest="col3" nameend="col3" align="center" valign="top">0010B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Receiver accepts error-free data packet</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">NAK</entry><entry namest="col3" nameend="col3" align="center" valign="top">1010B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Receiving device cannot accept data or transmitting device cannot send data</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">STALL</entry><entry namest="col3" nameend="col3" align="center" valign="top">1110B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Endpoint is halted or a control pipe request is not supported</entry></row><row><entry namest="col2" nameend="col2" align="left" valign="top">NYET</entry><entry namest="col3" nameend="col3" align="center" valign="top">0110B</entry><entry namest="col4" nameend="col4" align="left" valign="top">No response yet from receiver (see Sections 8.5.1 and 11.17-11.21)</entry></row><row rowsep="0"><entry namest="col1" nameend="col1" morerows="4" rowsep="1" align="left" valign="top">Special</entry><entry namest="col2" nameend="col2" align="left" valign="top">RRE</entry><entry namest="col3" nameend="col3" align="center" valign="top">1100B</entry><entry namest="col4" nameend="col4" align="left" valign="top">(Token) Host-issued preamble. Enables downstream bus traffic to low-speed devices.</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">ERR</entry><entry namest="col3" nameend="col3" align="center" valign="top">1100B</entry><entry namest="col4" nameend="col4" align="left" valign="top">(Handshake) Split Transaction Error Handshake (reuses PRE value)</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">SPLIT</entry><entry namest="col3" nameend="col3" align="center" valign="top">1000B</entry><entry namest="col4" nameend="col4" align="left" valign="top">(Token) High-speed Split Transaction Token (see Section 8.4.2)</entry></row><row rowsep="0"><entry namest="col2" nameend="col2" align="left" valign="top">PING</entry><entry namest="col3" nameend="col3" align="center" valign="top">0100B</entry><entry namest="col4" nameend="col4" align="left" valign="top">(Token) High-speed flow control probe for a bulk/control endpoint (see Section 8.5.1)</entry></row><row><entry namest="col2" nameend="col2" align="left" valign="top">Reserved</entry><entry namest="col3" nameend="col3" align="center" valign="top">0000B</entry><entry namest="col4" nameend="col4" align="left" valign="top">Reserved PID</entry></row></tbody></tgroup><tgroup cols="4" rowsep="0"><colspec colnum="1" colname="col1" colwidth="21mm" /><colspec colnum="2" colname="col2" colwidth="21mm" /><colspec colnum="3" colname="col3" colwidth="21mm" /><colspec colnum="4" colname="col4" colwidth="104mm" /><tbody><row><entry namest="col1" nameend="col4" align="justify" valign="top">*Note: PID bits are shown in MSb order. When sent on the USB, the rightmost bit (bit 0) will be sent first.</entry></row></tbody></tgroup></table></tables>

3. ADDRESS, END POINT, CRC5 FIELD <ol id="ol0003" ol-style=""><li>(1) Address =&gt; 7-bit, ADDR[6:0]</li><li>(2) End Point =&gt; 4-bit, EndP[3:0]</li><li>(3) Token CRC =&gt; 5-bit, TCRC[4:0] <maths id="math0005" num=""><math display="block"><mrow><mrow><mo>{</mo><mi mathvariant="normal">ADDR</mi><mrow><mo>[</mo><mn>6</mn><mo>:</mo><mn>0</mn><mo>]</mo><mo>&amp;</mo><mi mathvariant="normal">EndP</mi><mrow><mo>[</mo><mn>3</mn><mo>]</mo></mrow></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">EndP</mi><mrow><mo>[</mo><mn>2</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>&amp;</mo><mi mathvariant="normal">TCRC</mi><mrow><mo>[</mo><mn>4</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>}</mo></mrow></mrow></math><img file="EP1632864A2_D0005.tif" /></maths></li></ol> Where TCRC is a 5-bit Token CRC, and the CRC on the Mu card is optional. If CRC is turned on, the CRC check must exist on both of the host and device. If, however, CRC is disabled, Wrapper must generate a CRC for a USB controller. Since Default is disabled CRC, there is no CRC field when CRC is disabled.

4. EOP FIELD <ol id="ol0004" ol-style=""><li>(1) 1-bit: DAT0 = 1b</li><li>(2) 4-bit: DAT[3:0] = xxx1b</li><li>(3) 8-bit: DAT[7:0] = xxxxxxx1b</li><li>(4) 16-bit: DAT[15:0] = xxxxxxxxxxxxxxx1b</li></ol> Where "x" refers to a "don't care" condition. For solving an even/odd byte issue on the 16-bit mode transaction, OddByte bit is added on the b [15] of the EOP field. If OddByte=1, then the last byte on the DATA [15:8] is invalid. If OddByte=0, then the last word on the DATA [15:0] is valid.

5. TOKEN PACKET FORMAT Token Packet is composed of 3-byte SYNC and EOP. The Token packet supports at least the 1-bit, 4-bit and 8-bit modes. <ol id="ol0005" compact="compact" ol-style=""><li>(1) 1-bit: (LSB First) <maths id="math0006" num=""><math display="block"><mrow><mi mathvariant="normal">SYNC</mi><mo>+</mo><mi mathvariant="normal">PID</mi><mo>+</mo><mi mathvariant="normal">ADDR</mi><mo>+</mo><mi mathvariant="normal">ENDP</mi><mo>+</mo><mi mathvariant="normal">CRC</mi><mn>5</mn><mo>+</mo><mi mathvariant="normal">EOP</mi></mrow></math><img file="EP1632864A2_D0006.tif" /></maths></li><li>(2) 4-bit: {DAT[3:0]} <maths id="math0007" num=""><math display="block"><mrow><mtable columnalign="left"><mtr><mtd><mi mathvariant="normal">  SYNC</mi><mo>+</mo><mi mathvariant="normal">PID</mi><mo>+</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo></mrow><mo>+</mo><mi mathvariant="normal">A</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">ENDP</mi><mrow><mo>[</mo><mn>0</mn><mo>]</mo></mrow><mo>&amp;</mo><mi mathvariant="normal">A</mi><mrow><mo>[</mo><mn>6</mn><mo>:</mo><mn>4</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">CRC</mi><mn>0</mn></mrow></mtd></mtr><mtr><mtd><mo>&amp;</mo><mrow><mi mathvariant="normal">ENDP</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>1</mn><mo>]</mo></mrow><mo>}</mo><mo>+</mo><mi mathvariant="normal">CRC</mi><mrow><mo>[</mo><mn>5</mn><mo>:</mo><mn>1</mn><mo>]</mo><mo>+</mo><mi mathvariant="normal">EOP</mi></mrow></mrow></mtd></mtr></mtable></mrow></math><img file="EP1632864A2_D0007.tif" /></maths></li><li>(3) 8-bit mode: {DAT[7:0]} <maths id="math0008" num=""><math display="block"><mrow><mtable columnalign="left"><mtr><mtd><mi mathvariant="normal">  SYNC</mi><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo><mo>&amp;</mo><mi mathvariant="normal">PID</mi></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">EP</mi><mrow><mo>[</mo><mn>0</mn><mo>]</mo></mrow><mo>&amp;</mo><mi mathvariant="normal">A</mi><mrow><mo>[</mo><mn>6</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">TCRC</mi><mrow><mo>[</mo><mn>4</mn><mo>:</mo><mn>0</mn><mo>]</mo><mo>&amp;</mo></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mi mathvariant="normal">EP</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>1</mn><mo>]</mo></mrow><mo>}</mo><mo>+</mo><mrow><mi mathvariant="normal">EOP</mi></mrow></mrow></mtd></mtr></mtable></mrow></math><img file="EP1632864A2_D0008.tif" /></maths></li></ol>

5.1. Start-of-Frame Format

<maths id="math0009" num=""><math display="block"><mrow><mtable columnalign="left"><mtr><mtd><mi mathvariant="normal">  SYNC</mi><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo><mo>&amp;</mo><mi mathvariant="normal">PID</mi></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">FN</mi><mrow><mo>[</mo><mn>10</mn><mo>:</mo><mn>3</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">FN</mi><mrow><mo>[</mo><mn>2</mn><mo>:</mo><mn>0</mn><mo>]</mo><mo>&amp;</mo></mrow><mi mathvariant="normal">TCRC</mi><mrow><mo>[</mo><mn>4</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>}</mo></mrow></mtd></mtr><mtr><mtd><mrow><mo>+</mo><mrow><mi mathvariant="normal">EOP</mi></mrow></mrow></mtd></mtr></mtable></mrow></math><img file="EP1632864A2_D0009.tif" /></maths> Where FN refers to Frame Number.

6. DATA PACKET FORMAT

6.1. Data Field Format

<ul id="ul0001" list-style="none" compact="compact"><li>(i) 1-bit: (LSB first) <img file="EP1632864A2_D0010.tif" /></li><li>(ii) 4-bit <img file="EP1632864A2_D0011.tif" /></li><li>(iii) 8-bit <img file="EP1632864A2_D0012.tif" /></li><li>(iv) 16-bit <img file="EP1632864A2_D0013.tif" /></li></ul> Where the 16-bit mode is used only in Data Packet.

6.2. Data Packet Format

<maths id="math0010" num=""><math display="block"><mrow><mtable columnalign="left"><mtr><mtd><mi mathvariant="normal">  SYNC</mi><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo><mo>&amp;</mo><mi mathvariant="normal">PID</mi></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mrow><mo>{</mo><mi mathvariant="normal">DAT</mi><mrow><mo>[</mo><mn>7</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>}</mo><mo>*</mo><mrow><mo>(</mo><mn>0</mn><mo>∼</mo><mn>1024</mn><mo>)</mo></mrow><mo>+</mo></mrow><mo>{</mo><mi mathvariant="normal">DCRC</mi><mrow><mo>[</mo><mn>15</mn><mo>:</mo><mn>8</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo></mtd></mtr><mtr><mtd><mrow><mrow><mo>{</mo><mi mathvariant="normal">DCRC</mi><mrow><mo>[</mo><mn>7</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mi mathvariant="normal">EOP</mi></mrow></mrow></mtd></mtr></mtable></mrow></math><img file="EP1632864A2_D0014.tif" /></maths> Where DCRC is Data CRC with 16-bit Polynomial: X¹⁶+X¹⁵+X²+1 (SEED = 800Dh)

7. HANDSHAKE PACKET FORMAT <ol id="ol0006" compact="compact" ol-style=""><li>(1) 1-bit: (LSB First) <maths id="math0011" num=""><math display="block"><mrow><mi mathvariant="normal">SYNC</mi><mo>+</mo><mi mathvariant="normal">PID</mi><mo>+</mo><mi mathvariant="normal">EOP</mi></mrow></math><img file="EP1632864A2_D0015.tif" /></maths></li><li>(2) 4-bit: {DAT[3:0]} <maths id="math0012" num=""><math display="block"><mrow><mi mathvariant="normal">SYNC</mi><mo>+</mo><mi mathvariant="normal">PID</mi><mo>+</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo><mo>+</mo></mrow><mi mathvariant="normal">EOP</mi></mrow></math><img file="EP1632864A2_D0016.tif" /></maths></li><li>(3) 8-bit mode: {DAT[7:0]} <maths id="math0013" num=""><math display="block"><mrow><mi mathvariant="normal">SYNC</mi><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo><mo>&amp;</mo><mi mathvariant="normal">PID</mi></mrow><mo>}</mo><mo>+</mo></mrow><mi mathvariant="normal">EOP</mi></mrow></math><img file="EP1632864A2_D0017.tif" /></maths></li></ol>

8. SPECIAL PACKET FORMAT

8.1. Ping Format

<ul id="ul0002" list-style="none" compact="compact"><li>(i) 1-bit: (LSB First) <maths id="math0014" num=""><math display="block"><mrow><mi mathvariant="normal">SYNC</mi><mo>+</mo><mi mathvariant="normal">PID</mi><mo>+</mo><mi mathvariant="normal">ADDR</mi><mo mathvariant="normal">+</mo><mi mathvariant="normal">ENDP</mi><mo mathvariant="normal">+</mo><mi mathvariant="normal">CRC</mi><mn mathvariant="normal">5</mn><mo>+</mo><mi mathvariant="normal">EOP</mi></mrow></math><img file="EP1632864A2_D0018.tif" /></maths></li><li>(ii) 4-bit: {DAT[3:0]} <maths id="math0015" num=""><math display="block"><mrow><mtable columnalign="left"><mtr><mtd><mi mathvariant="normal">  SYNC</mi><mo>+</mo><mi mathvariant="normal">PID</mi><mo>+</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo></mrow><mo>+</mo><mi mathvariant="normal">A</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">ENDP</mi><mrow><mo>[</mo><mn>0</mn><mo>]</mo></mrow><mo>&amp;</mo><mi mathvariant="normal">A</mi><mrow><mo>[</mo><mn>6</mn><mo>:</mo><mn>4</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">CRC</mi><mn>0</mn><mi mathvariant="normal"> </mi><mo>&amp;</mo></mrow></mtd></mtr><mtr><mtd><mrow><mi mathvariant="normal">ENDP</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>1</mn><mo>]</mo></mrow><mo>}</mo><mo>+</mo><mi mathvariant="normal">CRC</mi><mrow><mo>[</mo><mn>5</mn><mo>:</mo><mn>1</mn><mo>]</mo><mo>+</mo><mi mathvariant="normal">EOP</mi></mrow></mrow></mtd></mtr></mtable></mrow></math><img file="EP1632864A2_D0019.tif" /></maths></li><li>(iii) 8-bit mode: {DAT[7:0]} <maths id="math0016" num=""><math display="block"><mrow><mtable columnalign="left"><mtr><mtd><mi mathvariant="normal">  SYNC</mi><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">not</mi><mrow><mo>(</mo><mi mathvariant="normal">PID</mi><mo>)</mo><mo>&amp;</mo><mi mathvariant="normal">PID</mi></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mo>{</mo><mi mathvariant="normal">EP</mi><mrow><mo>[</mo><mn>0</mn><mo>]</mo></mrow><mo>&amp;</mo><mi mathvariant="normal">A</mi><mrow><mo>[</mo><mn>6</mn><mo>:</mo><mn>0</mn><mo>]</mo></mrow><mo>}</mo></mrow><mo>+</mo><mrow><mrow><mo>{</mo><mi mathvariant="normal">TCRC</mi><mrow><mo>[</mo><mn>4</mn><mo>:</mo><mn>0</mn><mo>]</mo><mo>&amp;</mo><mi mathvariant="normal">EP</mi><mrow><mo>[</mo><mn>3</mn><mo>:</mo><mn>1</mn><mo>]</mo></mrow></mrow><mo>}</mo></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mo>+</mo><mi mathvariant="normal">EOP</mi></mrow></mrow></mtd></mtr></mtable></mrow></math><img file="EP1632864A2_D0020.tif" /></maths></li></ul>

9. TRANSFER TYPES The Transfer Types are inherent from the USB standard, including (1) Control, (2) Interrupt, (3) Bulk, and (4) Isochronous.

10. SIGNAL INTEGRITY A signal or data transportation in the bus has 3 kinds of protections: <ol id="ol0007" compact="compact" ol-style=""><li>(1) PID is protected by inverted mirror of PID and nPID. Where the nPID is an inverted signal of PID.</li><li>(2) Token Packet and Start-of-Frame are protected by CRC5, of which the Polynomial and the seed are as follows: <maths id="math0017" num=""><math display="block"><mrow><msup><mrow><mi mathvariant="normal">X</mi></mrow><mrow><mn>5</mn></mrow></msup><mo>+</mo><msup><mrow><mi mathvariant="normal">X</mi></mrow><mrow><mn>2</mn></mrow></msup><mo>+</mo><mn>1</mn><mi mathvariant="normal"> with SEED</mi><mo>=</mo><mn>01100</mn><mi mathvariant="normal">b</mi></mrow></math><img file="EP1632864A2_D0021.tif" /></maths></li><li>(3) Data Packet is protected by CRC 16, of which the Polynomial and the seed are as follows: <maths id="math0018" num=""><math display="block"><mrow><msup><mrow><mi mathvariant="normal">X</mi></mrow><mrow><mn>16</mn></mrow></msup><mo>+</mo><msup><mrow><mi mathvariant="normal">X</mi></mrow><mrow><mn>15</mn></mrow></msup><mo>+</mo><msup><mrow><mi mathvariant="normal">X</mi></mrow><mrow><mn>2</mn></mrow></msup><mo>+</mo><mn>1</mn><mi mathvariant="normal"> with SEED</mi><mo>=</mo><mn>800</mn><mi mathvariant="normal">Dh</mi></mrow></math><img file="EP1632864A2_D0022.tif" /></maths></li></ol>

11. BUS WIDTH AND SETTING The device is powered at the 1-bit bus mode. The host can set the bus width of 1-bit (initial), 4-bit, 8-bit, or 16-bit to be operated on both sides. <ol id="ol0008" compact="compact" ol-style=""><li>(1) 1-bit: Token (1-bit), Handshake (1-bit), Special (1-bit), Data (1-bit).</li><li>(2) 4-bit: Token (4-bit), Handshake (4-bit), Special (4-bit), Data (4-bit).</li><li>(3) 8-bit: Token (8-bit), Handshake (8-bit), Special (8-bit), Data (8-bit).</li><li>(4) 16-bit: Token (8-bit), Handshake (8-bit), Special (8-bit), Data (16-bit).</li></ol>

Fig. 4B is a proposed pin assignment chart of a removable electronic device in accordance with another embodiment of the present invention. Unlike the 20-pin assignment for a 16-bit application illustrated in Fig. 4A, Fig. 4B illustrates a 13-pin assignment for an 8-bit application. The eleventh and twelfth pins for the USB mode, defined for D- and D+, respectively, are used to determine whether the USB mode is selected. Furthermore, pins 11, 12 and 13 are defined for SIMM card applications.

Fig. 5 is a diagram of a removable electronic device 100 in accordance with one embodiment of the present invention. Referring to Fig. 5, electronic device 100 includes a notch 102 on the upper left-hand corner to prevent incorrect insertion of electronic device 100. In addition, notch 102 and related counter parts serve to allow for backward compatibility of MMC and USB applications, but not vice versa. In one aspect, notch 102 intersects the adjacent sides 104 and 106 with substantially the same angle, approximately 45 degrees.

Electronic device 100 also includes a plurality of interweaving contact pads labeled 1 to 20, which correspond to the pins illustrated in Fig. 4A. The interweaving design in the contact pads allows additional pins to be present in the same real estate. As a result, a different number of contact pads may alternately be used. The contact pads, connected with a memory circuit chip (not shown) within electronic device 100, are positioned in twenty recesses on a top surface along front side 104 and notch 102. The contact pads may be divided into a first row and a second row. Each of the contact pads includes a substantially tapered end such that contact pads of the first row are arranged with the corresponding contact pads of the second row by their substantially tapered ends. The substantially tapered ends allow smooth contact with the host's contact terminals.

Figs. 6A and 6B are diagrams of a removable electronic device 120 in accordance with another embodiment of the present invention. Fig. 6A is a top view of electronic device 120 having a housing (not numbered). Referring to Fig. 6A, the housing includes a top surface, a bottom surface and a periphery. Electronic device 120 includes a notch 122 and a substantially "U-shaped" indentation 124 on the periphery of the housing to allow for a low-profile design. Specifically, indentation 124 allows a card reader (not shown) in the host to grasp electronic device 120 and secure electronic device 120 through indentation 124, as opposed to the conventional application of using the bulk of the memory card to secure its position in the host. As such, the notch design of the memory card of the present invention obviates this consideration in the memory card design and in turn allows the design of the memory card to be minimized. Accordingly, the profile of the card reader in the host may also be minimized.

In addition to a plurality of interweaving contact pads (not numbered) positioned in a first row and a second row, electronic device 120 includes a contact pad 128 extending across the first row to the second row. In one embodiment, the total number of the first row of contact pads and the second row of contact pads is 20.

Fig. 6B is a bottom view of electronic device 120. Referring to Fig. 6B, electronic device 120 includes additional indentations 126 on the periphery to allow for locking of electronic device 120 to the housing at the host side.

It will be appreciated by those skilled in the art that changes could be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.