This manual covers the SanDisk MultiMediaCard which was developed by
SanDisk’s Design Center located in Tefen, Israel. The MultiMediaCard
supports version 1.4 of the MultiMediaCard Specification.
CORPORATE HEADQUARTERS
140 Caspian Court
Sunnyvale, CA 94089-1000
408-542-0500
FAX: 408-542-0503
URL: http://www.sandisk.com
Page 2
SanDisk® Corporation general policy does not recommend the use of its products in life support applications where in a
failure or malfunction of the product may directly threaten life or injury. Per SanDisk Terms and Conditions of Sale, the
user of SanDisk products in life support applications assumes all risk of such use and indemnifies SanDisk against all
damages.
The information in this manual is subject to change without notice.
SanDisk Corporation shall not be liable for technical or editorial errors or omissions contained herein; nor for incidental or
consequential damages resulting from the furnishing, performance, or use of this material.
All parts of the SanDisk MultiMediaCard documentation are protected by copyright law and all rights are reserved. This
documentation may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic
medium or machine readable form without prior consent, in writing, from SanDisk Corporation.
SanDisk and the SanDisk logo are registered trademarks of SanDisk Corporation.
Product names mentioned herein are for identification purposes only and may be trademarks and/or registered trademarks
of their respective companies.
SanDisk products are covered or licensed under one or more of the following U.S. Patent Nos. 5,070,032; 5,095,344;
5,168,465; 5,172,338; 5,198,380; 5,200,959; 5,268,318; 5,268,870; 5,272,669; 5,418,752; 5,602,987. Other U.S. and
foreign patents awarded and pending.
Lit. No. 80-13-00089 Rev 2 4/2000Printed in U.S.A.
Revision History
• Revisions dated before 1/98—initial release and general changes.
• Revision dated 1/98—general editorial changes, manual reorganized, technical changes to reflect support of
MultiMediaCard Specification version 1.3, new timing diagrams added. Pin 6 definition changed in SPI mode from SPI
select to VSS2 (supply voltage ground).
• Revision dated 4/98— changes reflect support of MultiMediaCard Specification version 1.4, updated timing for
Multiple Write with no Busy, updated SPI command class definition, added Error Protection section, changed
operating temperature specification to -25° to 85°C.
• Revision dated 4/28/98—Updated C_SIZE and C_SIZE_MULT field definitions.
• Revision 1 dated 4/99—Added 32 MB MultiMediaCard, general technical and editorial changes, added power up
section.
The SanDisk MultiMediaCard is a very small,
removable flash storage device, designed
specifically for storage applications that put a
premium on small form factor, low power and low
cost. Flash is the ideal storage medium for
portable, battery-powered devices. It features low
power consumption and is non-volatile, requiring
no power to maintain the stored data. It also has a
wide operating range for temperature, shock and
vibration.
The MultiMediaCard is well suited to meet the
needs of small, low power, electronic devices.
With a form factor of 32mm by 24mm and 1.4mm
thick, MultiMediaCards are expected to be used in
a wide variety of portable devices like mobile
phones, pagers and voice recorders. This ultrasmall form factor is part of a new, emerging,
proposed open standard.
To support this wide range of applications, the
MultiMediaCard protocol, a high performance
seven pin serial interface, is designed for
maximum scalability and configurability. A l l
device and interface configuration data (such as
maximum frequency, card identification, etc.) are
stored on the card.
The MultiMediaCard interface allows for easy
integration into any design, regardless of
microprocessor used. For compatibility with
existing controllers, the MultiMediaCard offers,
in addition to the MultiMediaCard interface, an
alternate communication protocol which is based
on the SPI standard.
The MultiMediaCard provides up to 32 million
bytes of memory using SanDisk Flash memory
chips which were designed by SanDisk especially
for use in mass storage applications. In addition to
the mass storage specific flash memory chip, the
MultiMediaCard includes an on-card intelligent
controller which manages interface protocols and
data storage and retrieval, as well as Error
Correction Code (ECC) algorithms, defect
handling and diagnostics, power management and
clock control.
MultiMediaCards are fully compatible with t he
MultiMediaCard standard specification listed
below:
The MultiMediaCard System Specification
Version 1.4
This specification may be obtained from:
MultiMediaCard Association
19672 Stevens Creek Blvd., Suite 404
Cupertino, CA 95014-2465
USA
Phone: 408-253-0441
Fax: 408-253-8811
Email: prophet2@mmca.org
http://www.mmca.org
1.5Functional Description
SanDisk MultiMediaCards contain a high level,
intelligent subsystem as shown in the block
diagram, Figure 1-1. This intelligent
(microprocessor) subsystem provides many
capabilities not found in other types of memory
cards. These capabilities include:
1. Host independence from details of erasing
and programming flash memory.
2. Sophisticated system for managing
defects (analogous to systems found in
magnetic disk drives).
3. Sophisticated system for error recovery
including a powerful error correction code
(ECC).
4.Power management for low power
operation.
1.5.1Flash Technology Independence
The 512 byte sector size of the MultiMediaCard is
the same as that in an IDE magnetic disk drive. To
write or read a sector (or multiple sectors), t he
host computer software simply issues a Read or
Write command to the MultiMediaCard. This
command contains the address. The host software
then waits for the command to complete. The host
software does not get involved in the details of
how the flash memory is erased, programmed or
read. This is extremely important as flash devices
are expected to get more and more complex in th e
future. Because the MultiMediaCard uses an
intelligent on-board controller, the host system
software will not require changing as new flash
memory evolves. In other words, systems that
support the MultiMediaCard today will be able
to access future SanDisk MultiMediaCards built
with new flash technology without having to
update or change host software.
1.5.2Defect and Error Management
MultiMediaCards contain a sophisticated defect
and error management system. This system is
analogous to the systems found in magnetic disk
drives and in many cases offers enhancements. For
instance, disk drives do not typically perform a
read after write to confirm the data is written
correctly because of the performance penalty that
would be incurred. MultiMediaCards do a read
after write under margin conditions to verify that
the data is written correctly. In the rare case that
a bit is found to be defective, MultiMediaCards
replace this bad bit with a spare bit within the
sector header. If necessary, MultiMediaCards
will even replace the entire sector with a spare
sector. This is completely transparent to the host
and does not consume any user data space.
The MultiMediaCard’s soft error rate
specification is much better than the magnetic
disk drive specification. In the extremely rare
case a read error does occur, MultiMediaCards
have innovative algorithms to recover the data.
This is similar to using retries on a disk drive but
is much more sophisticated. The last line of
defense is to employ a powerful ECC to correct t h e
data. If ECC is used to recover data, defective bits
are replaced with spare bits to ensure they do not
cause any future problems.
These defect and error management systems
coupled with the solid-state construction give
MultiMediaCards unparalleled reliability.
SanDisk MultiMediaCards have an endurance
specification for each sector of 300,000 writes
(reading a logical sector is unlimited). This is far
beyond what is needed in nearly all applications
of MultiMediaCards. Even very heavy use of t h e
MultiMediaCard in cellular phones, personal
communicators, pagers and voice recorders will use
only a fraction of the total endurance over t h e
typical device’s five year lifetime. For instance,
it would take over 34 years to wear out an area on
the MultiMediaCard on which a file of any size
(from 512 bytes to capacity) was rewritten 3 times
per hour, 8 hours a day, 365 days per year.
With typical applications the endurance limit is
not of any practical concern to the vast majority of
users.
1.5.4 Wear Leveling
When the host is ready to access t h e
MultiMediaCard and it is in sleep mode, any
command issued to the MultiMediaCard will
cause it to exit sleep and respond.
1.5.7Hot Insertion
Support for hot insertion will be required on th e
host but will be supported through the connector.
Connector manufacturers will provide connectors
that have power pins long enough to be powered
before contact is made with the other pins. Please
see connector data sheets for more details. This
approach is similar to that used in PCMCIA to
allow for hot insertion. This applies to both
MultiMediaCard and SPI modes.
1.5.8MultiMediaCard Mode
1.5.8.1MultiMediaCard Standard
Compliance
SanDisk MultiMediaCards do not require or
perform a Wear Level operation.
1.5.5Using the Erase Command
The Erase (sector or group) command provides t he
capability to substantially increase the write
performance of the MultiMediaCard. Once a
sector has been erased using the Erase command, a
write to that sector will be much faster. This is
because a normal write operation includes a
separate sector erase prior to write.
1.5.6Automatic Sleep Mode
A unique feature of the SanDisk MultiMediaCard
(and other SanDisk products) is automatic
entrance and exit from sleep mode. Upon
completion of an operation, the MultiMediaCard
will enter the sleep mode to conserve power if no
further commands are received within 5 msec. Th e
host does not have to take any action for this to
occur. In most systems, the MultiMediaCard is in
sleep mode except when the host is accessing i t ,
thus conserving power.
The MultiMediaCard is fully compliant with
MultiMediaCard Standard Specification V1.4.
The structure of the Card Specific Data (CSD)
register is compliant with CSD structure V1.4.
1.5.8.2Negotiating Operation Conditions
The MultiMediaCard supports the operation
condition verification sequence defined in th e
MultiMediaCard standard specifications. Should
the MultiMediaCard host define an operating
voltage range which is not supported by the
MultiMediaCard it will put itself in an inactive
state and ignore any bus communication. The only
way to get the card out of the inactive state is by
powering it down and up again.
In Addition the host can explicitly send the card
to the inactive state by using t h e
GO_INACTIVE_STATE command.
The MultiMediaCard bus is a single master
(MultiMediaCard host) and multi-slaves (cards)
bus. The host can query the bus and find out how
many cards of which type are currently connected.
The MultiMediaCard’s CID register is preprogrammed with a unique card identification
number which is used during the acquisition and
identification procedure.
In addition, the MultiMediaCard host can read
the card’s CID register using the READ_CID
MultiMediaCard command. The CID register is
programmed during the MultiMediaCard testing
and formatting procedure, on the manufacturing
floor. The MultiMediaCard host can only read
this register and not write to it.
1.5.8.4Card Status
MultiMediaCard status is stored in a 32 bit status
register which is sent as the data field in the card
respond to host commands. Status register
provides information about the card’s current state
and completion codes for the last host command.
The card status can be explicitly read (polled)
with the SEND_STATUS command.
Although the MultiMediaCard memory space is
byte addressable with addresses ranging from 0 to
the last byte, it is not a simple byte array but
divided into several structures.
Memory bytes are grouped into 512 byte blocks
called sectors. Every block can be read, written
and erased individually.
Sectors are grouped into erase groups of 16 or 32
sectors depending on card size. Any combination of
sectors within one group or, any combination of
erase groups can be erased in a single erase
command. A write command implicitly erases th e
memory before writing new data into it. Explicit
WP Group 2
WP Group 1
Erase Group
erase command can be used for pre-erasing of
memory which will speed up the next write
operation.
Erase groups are grouped into Write Protect Groups
(WPG) of 32 erase groups. The write/erase access
to each WPG can be limited individually. A
diagram of the memory structure hierarchy is
shown in Figure 1-2.
The number of various memory structures, for th e
different MultiMediaCards are summarized in
Table 1-3. The last (highest in address) WPG will
be smaller and contain less than 32 erase groups.
The MultiMediaCard supports three read/write
modes as shown in the above figure.
Stream Mode
In stream mode the host reads or writes continues
stream of data. The starting address is specified
in the read/write command and the operation
ends when the host sends a stop transmission
command.
In this mode there is no validity check on th e
transferred data.
The start address for a read operation can be any
random byte address in the valid address space of
the memory card. For a write operation, the start
address must be sector aligned and the data length
must be an integer multiplication of the sector
length.
Single Block Mode
In this mode the host reads or writes one data
block in a pre-specified length. The data block
transmission is protected with 16 bit CRC which
is generated by the sending unit and checked by
the receiving unit.
The block length, for read operations, is limited
by the device sector size (512 bytes) but can be as
small as a single byte. Misalignment is not
allowed. Every data block must be contained in a
single physical sector.
The block length for write operations must be
identical to the sector size and the start address
aligned to a sector boundary.
Multiple Block Mode
This mode is similar to the single block mode, but
the host can read/write multiple data blocks (all
have the same length) which will be stored or
retrieved from contiguous memory addresses
starting at the address specified in the command.
The operation is terminated with a stop
transmission command.
Misalignment and block length restrictions apply
to multiple blocks as well and are identical to t he
single block read/write operations.
1.5.8.7Data Protection in the Flash Card
1.5.8.8Erase
The smallest erasable unit in th e
MultiMediaCard is a sector. In order to speed up
the erase procedure, multiple sectors can be erased
in the same time. The erase operation is divided
into two stages:
Tagging - Selecting the Sectors for Erasing
To facilitate selection, a first command with t he
starting address is followed by a second command
with the final address, and all sectors within this
range will be selected for erase. After a range is
selected, individual sectors (or groups) within
that range can be removed using the UNTAG
command.
Erasing - Starting the Erase Process
The sectors are grouped into erase groups of 16 or 32
sectors. Tagging can address sectors or erase
groups. Either an arbitrary set of sectors within a
single erase group, or an arbitrary selection of
erase groups may be erased at one time, but not
both together. That is, the unit of measure for
determining an erase is either a sector or an erase
group, but if a sector, all selected sectors must l i e
within the same erase group. Tagging and erasing
sectors must follow a strict command sequence.
1.5.8.9Write Protection
The MultiMediaCard erase groups are grouped
into write protection groups. Commands a re
provided for limiting and enabling write and
erase privileges for each group individually. The
current write protect map can be read using t h e
SEND_WRITE_PROT command.
In addition two, permanent and temporary, card
level write protection options are available. Both
can be set using the PROGRAM_CSD command
(see below). The permanent write protect bit, once
set, cannot be cleared. This feature is implemented
in the MultiMediaCard controller firmware and
not with a physical OTP cell.
Every sector is protected with an Error Correction
Code (ECC). The ECC is generated (in the memory
card) when the sectors are written and validated
when the data is read. If defects are found, th e
data is corrected prior to transmission to the host.
The content of a MultiMediaCard can be marked
as an original or a copy using the copy bit in th e
CSD register. Once the Copy bit is set (marked as
a copy) it cannot be cleared. The Copy bit of the
MultiMediaCard is programmed (during test and
formatting on the manufacturing floor) as a copy.
The MultiMediaCard can be purchased with th e
copy bit set (copy) or cleared, indicating the card
is a master. This feature is implemented in t he
MultiMediaCard controller firmware and not
with a physical OTP cell.
1.5.8.11The CSD Register
All the configuration information of the
MultiMediaCard is stored in the CSD register.
The MSB bytes of the register contain
manufacturer data and the two least significant
bytes contain the host controlled data—the card
Copy and write protection and the user ECC
register.
1.5.9.2Card Acquisition and Identification
The card acquisition and identification function of
the MultiMediaCard bus is not supported in S PI
mode. The host must know the number of cards
currently connected on the bus. Specific card
selection is done via the CS signal.
1.5.9.3Card Status
In SPI mode only 16 bits (containing the errors
relevant to SPI mode) can be read out of t h e
MultiMediaCard status register.
1.5.9.4Memory Array Partitioning
Memory partitioning in SPI mode is equivalent to
MultiMediaCard mode. All read and write
commands are byte addressable.
1.5.9.5Read and Write Operations
The host can read the CSD register and alter the
host controlled data bytes using the SEND_CSD
and PROGRAM_CSD commands.
1.5.9SPI Mode
The SPI mode is a secondary communication
protocol for MultiMediaCards. This mode is a
subset of the MultiMediaCard protocol, designed
to communicate with an SPI channel, commonly
found in Motorola’s (and lately a few other
vendors’) microcontrollers.
1.5.9.1Negotiating Operating Conditions
The operating condition negotiation function of
the MultiMediaCard bus is not supported in S PI
mode. The host must work within the valid
voltage range (2.7 to 3.6) volts of the card.
In SPI mode, only single block read/write mode i s
supported.
1.5.9.6Data Transfer Rate
Same as for the MultiMediaCard mode when the
card is operating in single block read/write mode.
The MultiMediaCard has seven exposed contacts on one side. (See Figure 2-1.) The host is connected to
the MultiMediaCard using a seven pin connector as shown in the Appendix at the end of this manual.
The ROD is switched on and off by the host
synchronously to the open-drain and push-pull
mode transitions. R
and R
DAT
are pull-up
CMD
resistors protecting the CMD and the DAT line
against bus floating when no card is inserted or
when all card drivers are in a hi-impedance
mode.
R
CMD
CMD
DAT
CLK
C1C2C
3
1 2 3 4 5 6 7
MultiMediaCard
4.2.1Power Protection
Cards can be inserted/removed into/from the bus
without damage. If one of the supply pins (V
VSS) is not connected properly, then the current is
drawn through a data line to supply the card.
DD
or
A constant current source can replace the ROD in
order to achieve a better performance (constant
slopes for the signal rising and falling edges). If
the host does not allow the switchable R
implementation, a fix R
can be used.
CMD
OD
Consequently the maximum operating frequency in
the open drain mode has to be reduced in this case.
Hot Insertion/Removal
Hot insertion and removal are allowed. The
SanDisk MultiMediaCard will not be damaged by
inserting or removing it into the MultiMediaCard
bus even when the power is up.
•The inserted card will be properly reset
also when CLK carries a clock frequency
fPP.
•Data transfer failures induced by
removal/insertion should be detected by
the bus master using the CRC codes which
suffix every bus transaction.
Every cards output must also be able to withstand
short cuts to either supply.
If the hot insertion feature is implemented in the
host, the host has to withstand a shortcut
between V
DD
and V
without damage.
SS
4.2.2Programmable Card Output Driver
This option, defined in chapter 6 of th e
MultiMediaCard standard, is not implemented in
the SanDisk MultiMediaCard.
The MultiMediaCard SPI interface is compatible
with SPI hosts available on the market. As any
other SPI device the MultiMediaCard SPI
channel consists of the following 4 signals:
• CS: Host to card Chip Select signal.
• CLK: Host to card clock signal
• DataIn: Host to card data signal.
• DataOut: Card to host data signal.
Another SPI common characteristic, which is
implemented in the MultiMediaCard as well, is
byte transfers. All data tokens are multiples of 8
bit bytes and always byte aligned to the CS
signal.
The SPI standard defines the physical link only
and not the complete data transfer protocol. The
MultiMediaCard uses a subset of t h e
MultiMediaCard protocol and command set.
Power
Supply
The MultiMediaCard identification and
addressing algorithms are replaced by a
hardware Chip Select (CS) signal. There are no
broadcast commands. A card (slave) is selected,
for every command, by asserting (active low) t h e
CS signal (see Figure 4-2).
The CS signal must be continuously active for th e
duration of the SPI transaction (command,
response and data). The only exception is card
programming time. At this time the host can deassert the CS signal without affecting t he
programming process.
The bidirectional CMD and DAT lines are
replaced by unidirectional dataIn and dataOut
signals. This eliminates the ability of executing
commands while data is being read or written and,
therefore, eliminates the sequential and multi
block read/write operations. Only single block
read/write is supported by the SPI channel.
The power up of the MultiMediaCard bus is handled locally in each MultiMediaCard and in the bus
master.
After power-up (including hot insertion, that is,
inserting a card when the bus i s operating), th e
MultiMediaCard enters the Idle State. During
this state, the MultiMediaCard ignores all bus
transactions until CMD1 is received.
CMD1 is a special synchronization command used
to negotiate the operation voltage range and to
poll the cards until they are out of their power-up
sequence. Besides the operation voltage profile of
the cards, the response to CMD1 contains a busy
flag, indicating that the card is still working on
its power-up procedure and is not ready for
identification. This bit informs the host that a t
least one card is not ready. The host has to wait
(and continue to poll the cards) until this bit is
cleared.
Page 23
MultiMediaCard Product Manual
Getting individual cards, as well as the whole
MultiMediaCard system, out of Idle State is up to
the responsibility of the bus master. Since t he
power-up time and the supply ramp up time
depend on application parameters such as th e
maximum number of MultiMediaCards, the bus
length and the power supply unit, the host must
ensure that the power is built up to the operating
level (the same level which will be specified in
After power-up, the host starts the clock and
sends the initializing sequence on the CMD line.
This sequence is a contiguous stream of logical
ones. The sequence length is the maximum of one
msec, 74 clocks or the supply ramp up time. The
additional ten clocks (beyond the 64 clocks after
which the card should be ready for
communication) are provided to eliminate powerup synchronization problems.
CMD1) before CMD1 is transmitted.
4.4.2Bus Operating Conditions
SPI Mode bus operating conditions are identical to MultiMediaCard Mode bus operating conditions. The
CS (chip select) signal timing is identical to the input signal timing. (See Figure 4-5.)
General
ParameterSymbolMin.Max.UnitRemark
Peak voltage on all lines-0.53.6V
All Inputs
Input Leakage Current-1010
µA
All Outputs
Output Leakage Current-1010
µA
Power supply voltage
ParameterSymbolMin.Max.UnitRemark
Supply voltageV
Supply voltage differentials (V
SS1
, V
)-0.50.5V
SS2
DD
2.03.6V
The current consumption of any card during the power-up procedure must not exceed 10 mA.
The total capacitance CL of each line of the MultiMediaCard bus is the sum of the bus master
capacitance CHOST, the bus capacitance CBUS itself and the capacitance CCARD of each card
connected to this line:
CL = CHOST + CBUS + N∗CCARD
where N is the number of connected cards. Requiring the sum of the host and bus capacitances not to
exceed 30 pF for up to 10 cards, and 40 pF for up to 30 cards, the following values must not be exceeded:
ParameterSymbolMin.Max.UnitRemark
Pull-up resistanceRCMD
RDAT
Bus signal line capacitanceCL250pF
50100
kΩ
To prevent bus floating
fPP # 5 MHz,
30 cards
Bus signal line capacitanceCL100pF
Single card capacitanceCCARD7pF
Maximum signal line inductance16nH
4.4.3Bus Signal Levels
As the bus can be supplied with a variable supply voltage, all signal levels are related to the supply
voltage.
The input levels are identical with the push-pull mode bus signal levels.
4.4.5Push-pull Mode Bus Signal Level
To meet the requirements of the JEDEC specification JESD8-1A, the card input and output voltages
shall be within the following specified ranges for any VDD of the allowed voltage range:
ParameterSymbolMin.Max.UnitConditions
Output HIGH voltageVOH
Output LOW voltageVOL
Input HIGH voltageVIH
0.75∗VDD
0.625∗VDD
0.125∗VDD
VDD + 0.3V
V
V
V
IOH = -100 µA
IOH=-100 µA
@V
(min.)
DD
IOL=100 µA
@V
(min.)
DD
Input LOW voltageVILVSS-0.3
4.4.6Bus Timing
Clock
Input
Output
Note:Data in the shaded areas is not valid.
0.25∗VDD
T
PP
t
THL
t
WL
t
TLH
t
ISU
t
OSU
t
WH
t
IH
t
OH
V
V
IH
V
IL
V
IH
V
IL
V
O
V
OL
Figure 4-5 Timing Diagram Data Input/Output Referenced to Clock
ParameterSymbolMin.Max.UnitRemark
Clock CLK (All values are referred to min. (VIH) and max. (VIL)
Clock Frequency Data Transfer Mode
(PP)
f
PP
020MHzCL ≤ 100 pF
(10 cards)
Clock Frequency Identification Mode
(OD)
Clock Low Timet
Clock High Timet
Clock Rise Timet
Clock Fall Timet
Clock Low Timet
Clock High Timet
Clock Rise Timet
Clock Fall Timet
Inputs CMD, DAT (referenced to CLK)
Input set-up timet
Input hold timet
Outputs CMD, DAT (referenced to CLK)
Output set-up timet
Output hold timet
f
OD
WL
WH
TLH
THL
WL
WH
TLH
THL
ISU
OSU
OH
0400kHzCL ≤ 250 pF
(30 cards)
10nsCL ≤ 100 pF
(10 cards)
10nsCL ≤ 100 pF
(10 cards)
10nsCL ≤ 100 pF
(10 cards)
10nsCL ≤ 100 pF
(10 cards)
50nsCL ≤ 250 pF
(30 cards)
50nsCL ≤ 250 pF
(30 cards)
50nsCL ≤ 250 pF
(30 cards)
50nsCL ≤ 250 pF
(30 cards)
3ns
IH
3ns
5ns
5ns
4.5MultiMediaCard Registers
There is a set of six registers within the card interface. The OCR, CID and CSD registers carry the card
configuration information. The RCA register holds the card relative communication address for th e
current session. The DSR register is not implemented in the SanDisk MultiMediaCard.
4.5.1Operating Conditions Register (OCR)
The 32-bit operation conditions register stores the VDD voltage profile of the card. The
MultiMediaCard is capable of executing the voltage recognition procedure (CMD1) with any standard
MultiMediaCard host using operating voltages form 2 to 3.6 Volts.
Accessing the data in the memory array, however, requires 2.7 to 3.6 Volts. The OCR shows the voltage
range in which the card data can be accessed. The structure of the OCR register is described in Table 4-4.
The level coding of the OCR register is as follows:
•restricted voltage windows=LOW
•card busy=LOW (bit 31)
The least significant 31 bits are constant and will be set as described in Figure 4-6. If set, bit 32, the busy
bit, informs the host that the card power up procedure is finished.
00h
24
FFh
16
80h
8
00h
0
Reserved
Operating
Voltage Range
2.7 – 3.6 volt
Reserved
Busy Bit
Figure 4-6 OCR Structure
4.5.2DSR Register
The DSR Register is not implemented in SanDisk
MultiMediaCards.
controlled and assigned by
the MultiMediaCard
Association.
(offset from 1997)
4.5.4CSD Register
The Card Specific Data (CSD) register contains
all the configuration information required in order
to access the card data.
In the table below, the cell type column defines
the CSD field as Read only (R), One Time
Programmable (R/W) or erasable (R/W/E). This
table shows, for each field, the value in “real
world” units and coded according to the CSD
structure. The Model dependent column marks
(with a check mark—√) the CSD fields which are
model dependent.
The following sections describe the CSD fields and the relevant data types. If not explicitly defined
otherwise, all bit strings are interpreted as binary coded numbers starting with the left bit first.
CSD_STRUCTURE—describes the version of the CSD structure.
Table 4-7 CSD Register Structure
CSD_STRUCTURECSD Structure VersionValid for MultiMediaCard Protocol
0CSD version No. 1.0MultiMediaCard protocol version 1.0-1.2
1CSD version No. 1.1MultiMediaCard protocol version 1.4
2-3reserved
Version
MMC_PROT—Defines the MultiMediaCard protocol version supported by the card. It includes t h e
definition of the command set and the card responses. The card identification procedure is compatible
for all protocol versions.
NSAC—Defines the worst case for the clock dependent factor of the data access time. The unit for
NSAC is 100 clock cycles. Therefore, the maximal value for the clock dependent part of the read access
time is 25.5k clock cycles.
The total read access time N
as expressed in the Table 5-12 is the sum of TAAC and NSAC. It has to
AC
be computed by the host for the actual clock rate. The read access time should be interpreted as a
typical delay for the first data bit of a data block or stream from the end bit on the read commands.
TRAN_SPEED—The following table defines the maximum data transfer rate TRAN_SPEED:
CCC—The MultiMediaCard command set is divided into subsets (command classes). The card command
class register CCC defines which command classes are supported by this card. A value of ‘1’ in a CCC bit
means that the corresponding command class is supported. For command class definition refer to
Table 5-2.
Table 4-11 Supported Card Command Classes
CCC bitSupported Card Command Class
0class 0
1class 1
......
11class 11
READ_BL_LEN—The data block length is computed as 2
READ_BL_LEN
. The block length might therefore
be in the range 1, 2,4...2048 bytes:
Table 4-12 Data Block Length
READ_BL_LENBlock LengthRemark
02
12
......
11211 = 2048 Bytes
12-15reserved
0
= 1 Byte
1
= 2 Bytes
READ_BL_PARTIAL—Defines whether partial block sizes can be used in block read commands.
READ_BL_PARTIAL=0 means that only the READ_BL_LEN block size can be used for block oriented
data transfers.
READ_BL_PARTIAL=1 means that smaller blocks can be used as well. The minimum block size will be
equal to minimum addressable unit (one byte)
WRITE_BLK_MISALIGN—Defines if the data block to be written by one command can be spread over
more than one physical block of the memory device. The size of the memory block is defined in
WRITE_BL_LEN.
WRITE_BLK_MISALIGN=0 signals that crossing physical block boundaries is invalid.
WRITE_BLK_MISALIGN=1 signals that crossing physical block boundaries is allowed.
READ_BLK_MISALIGN—Defines if the data block to be read by one command can be spread over more
than one physical block of the memory device. The size of the memory block is defined in
READ_BL_LEN.
READ_BLK_MISALIGN=0 signals that crossing physical block boundaries is invalid.
READ_BLK_MISALIGN=1 signals that crossing physical block boundaries is allowed.
DSR_IMP—Defines if the configurable driver stage is integrated on the card. If set, a driver stage
register (DSR) must be implemented also.
C_SIZE (Device Size)—This parameter is used to compute the card capacity. The memory capacity of
the card is computed from the entries C_SIZE, C_SIZE_MULT and READ_BL_LEN as follows:
memory capacity = BLOCKNR * BLOCK_LEN
where
BLOCKNR = (C_SIZE+1) * MULT
MULT = 2
BLOCK_LEN = 2
C_SIZE_MULT+2
READ_BL_LEN
(C_SIZE_MULT < 8)
(READ_BL_LEN < 12)
Therefore, the maximum capacity which can be coded is 4096*512*2048 = 4 GBytes. Example: A four
MByte card with BLOCK_LEN = 512 can be coded with C_SIZE_MULT = 0 and C_SIZE = 2047.
VDD_R_CURR_MIN, VDD_W_CURR_MIN—The minimum values for read and write currents on
VDD power supply are coded as follows:
Table 4-14 V
Minimum Current Consumption
DD
VDD_R_CURR_MIN
Code For Current Consumption @ V
VDD_W_CURR_MIN
2:00=0.5mA; 1=1mA; 2=5mA; 3=10mA; 4=25mA;
5=35mA; 6=60mA; 7=100mA
DD
VDD_R_CURR_MAX, VDD_W_CURR_MAX—The maximum values for read and write currents on
VDD power supply are coded as follows:
Table 4-15 VDD Maximum Current Consumption
VDD_R_CURR_MAX
VDD_W_CURR_MAX
2:00=1mA; 1=5mA; 2=10mA; 3=25mA; 4=35mA;
Code For Current Consumption @ V
5=45mA; 6=80mA; 7=200mA
DD
C_SIZE_MULT (Device Size Multiplier)—This parameter is used for coding a factor MULT for
computing the total device size (see ‘C_SIZE’). The factor MULT is defined as 2
SECTOR_SIZE—The size of an erasable sector. The contents of this register is a 5 bit binary coded
value, defining the number of write blocks (see WRITE_BL_LEN). The actual size is computed by
increasing this number by one. A value of zero means 1 write block, 31 means 32 blocks.
ERASE_GRP_SIZE—The size of an erasable group. The contents of this register is a 5 bit binary coded
value, defining the number of sectors (see SECTOR_SIZE). The actual size is computed by increasing
this number by one. A value of zero means 1 sector, 31 means 32 sectors.
WP_GRP_SIZE—The size of a write protected group. The contents of this register is a 5 bit binary coded
value, defining the number of Erase Groups (see ERASE_GRP_SIZE). The actual size is computed by
increasing this number by one. A value of zero means 1 erase group, 31 means 32 erase groups.
WP_GRP_ENABLE—A value of ‘0’ means no group write protection possible.
DEFAULT_ECC—Set by the card manufacturer. It defines the ECC code which is recommended for use.
The field definition is the same as for the ECC field described later.
R2W_FACTOR—Defines the typical block program time as a multiple of the read access time. The
following table defines the field format.
Table 4-17 R2W_FACTOR
R2W_FACTORMultiples of Read Access Time
01
12 (write half as fast as read)
24
38
416
532
6,7reserved
WRITE_BL_LEN—Block length for write operations. See READ_BL_LEN for field coding.
WRITE_BL_PARTIAL—Defines whether partial block sizes can be used in block write commands.
WRITE_BL_PARTIAL=‘0’ means that only the WRITE_BL_LEN block size can be used for block
oriented data write.
WRITE_BL_PARTIAL=‘1’ means that smaller blocks can be used as well. The minimum block size is one
byte.
COPY—This bit marks the card as an original (‘0’) or non-original (‘1’). Once set to non-original, this
bit cannot be reset to original. The definition of “original” and “non-original” is application dependent
and changes no card characteristics.
PERM_WRITE_PROTECT—Permanently protects the whole card content against overwriting or
erasing (all write and erase commands for this card are permanently disabled). The default value is ‘0’,
i.e. not permanently write protected.
TMP_WRITE_PROTECT—Temporarily protects the whole card content from being overwritten or
erased (all write and erase commands for this card are temporarily disabled). This bit can be set and
reset. The default value is ‘0’, i.e. not write protected.
ECC—Defines the ECC code that was used for storing data on the card. This field is used by the host (or
application) to decode the user data. The following table defines the field format:
Table 4-18 ECC Type
ECCECC TypeMaximum Number Of Correctable Bits Per Block
0none (default)none
1BCH (542,512)3
2-3reserved-
CRC—The CRC field carries the check sum for the CSD contents. The checksum has to be recalculated
by the host for any CSD modification. The default corresponds to the initial CSD contents.
4.5.5Status Register
The MultiMediaCard status register structure i s
defined in the following table. The Type and
Clear-Condition fields in the table are coded as
follows:
Type:
• E - Error bit.
• S - Status bit.
• R - Detected and set for the actual
command response.
• X - Detected and set during command
execution. The host must poll the card by
sending status command in order to read
these bits.
Clear Condition:
• A - According to the card current state.
• B - Always related to the previous
command. Reception of a valid command
will clear it (with a delay of one
command).
The commands argument was out of allowed range for this card.C
A misaligned address, which did not match the block length was
used in the command.
The transferred block length is not valid.C
An error in the sequence of erase commands occurred.C
An invalid selection, sectors or groups, for erase.C
The command tried to write a write protected block.C
The CRC check of the previous command failed.B
Command not legal for the current stateB
A general or an unknown error occurred during the operation.C
The card could not sustain data transfer in stream read modeC
The card could not sustain data programming in stream write
mode
Can be one of the following errors:
- The CID register has been already written and can not be
overwritten.
- The read only section of the CSD does not match the card
content.
- An attempt to reverse the copy (set as original) or permanent
WP (unprotect) bits was made.
Only partial address space was erased due to existing WP
blocks.
An erase sequence was cleared before executing because an out
of erase sequence command was received
The state of the card when the command was received. If the
command execution causes a state change, it will be visible to
the host in the response to the next command. The four bits are
interpreted as a binary coded number between 0 and 15.
Corresponds to buffer empty signaling on the bus. (RDY/BSY)A
The 16-bit relative card address register carries
the card address assigned by the host during t h e
card identification. This address is used for t he
addressed host-card communication after the card
identification procedure. The default value of the
RCA register is 0x0001. The value 0x0000 is
reserved to set all cards in Stand-by State with
CMD7.
In SPI mode, only the MultiMediaCard CSD and
CID registers are accessible. Their format is
identical to the format in the MultiMediaCard
mode. However, a few fields are irrelevant in SPI
mode.
In SPI mode, the card status register has a
different, shorter, format as well. Refer to the SPI
Protocol section for more details.
Table 4-20 MultiMediaCard Registers in SPI Mode
NameAvailable in
SPI Mode
CIDYes16Card identification data (serial number, manufacturer ID etc.)
RCANo
DSRNo
CSDYes16Card specific data, information about the card operation conditions.
All communication between the host and
MultiMediaCards is controlled by the host
(master). The host sends commands of two types:
broadcast and addressed (point-to-point)
commands.
•Broadcast Commands
Broadcast commands are intended for a l l
MultiMediaCards. Some of these commands
require a response.
•Addressed (Point-to-Point) Commands
The addressed commands are sent to the addressed
MultiMediaCard and cause a response from this
card.
A general overview of the command flow is shown
in Figure 5-1 for the Card Identification Mode and
in Figure 5-2 for the Data Transfer Mode. The
commands are listed in the command tables (Table
5-3 through Table 5-9). The dependencies between
the current MultiMediaCard state, received
command and following state are listed in Table
5-10. In the following sections, the different card
operation modes will be described first.
Thereafter, the restrictions for controlling th e
clock signal are defined. All MultiMediaCard
commands together with the corresponding
responses, state transitions, error conditions and
timings are presented in the following sections.
Three operation modes are defined for
MultiMediaCards:
•Card Identification Mode
The host will be in card identification mode after
reset and while it is looking for new cards on t he
bus. MultiMediaCards will be in this mode after
reset until the SET_RCA command (CMD3) is
received.
•Interrupt Mode
The Interrupt Mode option defined in th e
MultiMediaCard Standard is not implemented on
the SanDisk MultiMediaCard.
•Data Transfer Mode
MultiMediaCards will enter data transfer mode
once an RCA is assigned to them. The host will
enter data transfer mode after identifying all the
MultiMediaCards on the bus.
The following table shows the dependencies
between bus modes, operation modes and card
states. Each state in the MultiMediaCard state
diagram (Figure 5-1 and Figure 5-2) is associated
with one bus mode and one operation mode:
Table 5-1 Bus Modes Overview
Card StateOperation ModeBus Mode
Inactive StateInactive
Idle State
Ready StateCard Identification ModeOpen-Drain
Identification State
Stand-by State
Transfer State
Sending-data StateData Transfer ModePush-Pull
Receive-data State
Programming State
Disconnect State
If a command with improper CRC was received, i t
is ignored. If there was a command execution (e.g.
continuous data read) the card continues in t he
operation until it gets a correct host command.
Page 39
5.2Card Identification Mode
All the data communication in the Card
Identification Mode uses only the command line
(CMD).
MultiMediaCard Product Manual
Figure 5-1 MultiMediaCard State Diagram (Card Identification Mode)
5.2.1Reset
GO_IDLE_STATE (CMD0) is the software reset
command and sets all MultiMediaCards to Idle
State regardless of the current card state.
MultiMediaCards in Inactive State are not
affected by this command.
After power-on by the host, all MultiMediaCards
are in Idle State, including the cards that were in
Inactive State. Note that at least 74 clock cycles
are required prior to starting bus communication.
After power-on or CMD0, all MultiMediaCards’
output bus drivers are in a high-impedance state.
The host drives the bus at the identification clock
rate fOD (generated by a push-pull driver stage).
Page 40
MultiMediaCard Product Manual
5.2.2Operating Voltage Range Validation
The MultiMediaCard standard requires that al l
MultiMediaCards will be able to establish
communication with the host using any operating
voltage between VDD-min and VDD-max. However,
during data transfer minimum and maximum
values for V
are defined in the card specific
DD
data register (CSD) and may not cover the whole
range. MultiMediaCard hosts are expected to read
the card’s CSD register and select proper V
DD
values or reject the card.
MultiMediaCards that store the CID and CSD
data in the payload memory can communicate this
information only under data-transfer V
DD
conditions. This means if host and card have non
compatible V
ranges, the card will not be able to
DD
complete the identification cycle, nor to send CSD
data.
SEND_OP_COND (CMD1) is designed to provide
MultiMediaCard hosts with a mechanism to
identify and reject cards which do not match t he
host’s desired V
the host sending the required V
range. This is accomplished by
DD
voltage window
DD
as the operand of this command.
MultiMediaCards which can not perform data
transfer in the specified range must discard
themselves from further bus operations and go into
Inactive State. All other MultiMediaCards will
respond concurrently (same method as card
identification) sending back their VDD range. The
wired-or result of the response will show a l l
voltage ranges which some of the cards do not
support.
By omitting the voltage range in the command,
the host can query the MultiMediaCard stack and
determine if there are any non compatibilities
before sending out-of-range cards into the Inactive
State. Bus query should be used if the host can
select a common voltage range or wants to notify
the application of non usable cards in the stack.
The busy bit in the CMD1 response can be used by a
card to tell the host that it is still working on it s
power-up/reset procedure (e.g. downloading the
register information from memory field) and is not
ready yet for communication. In this case the host
must repeat CMD1 until the busy bit is cleared.
During the initialization procedure, the host is
not allowed to change the OCR values. Changes in
the OCR content will be ignored by t he
MultiMediaCard. If there is a real change in th e
operating conditions the host must reset the card
stack (using CMD0) and begin the initialization
procedure once more.
GO_INACTIVE_STATE (CMD15) can also be used
to send an addressed MultiMediaCard into the
Inactive State. This command is used when t h e
host explicitly wants to deactivate a card (e.g.
host is changing V
into a range which is known
DD
to be not supported by this card).
5.2.3Card Identification Process
The host starts the card identification process in
open-drain mode with the identification clock
rate fOD. The open drain driver stages on the CMD
line allow parallel card operation during card
identification.
After the bus is activated and a valid operation
condition is obtained, the host then asks all cards
for their unique card identification (CID) number
with the broadcast command ALL_SEND_CID
(CMD2). All remaining unidentified cards (i.e.
those which are in Ready State) simultaneously
start sending their CID numbers serially, while
bit-wise monitoring their outgoing bit stream.
Those cards, whose outgoing CID bits do not match
the corresponding bits on the command line in any
one of the bit periods, stop sending their CID
immediately and must wait for the next
identification cycle (cards stay in the Ready
State). Since CID numbers are unique for each
MultiMediaCard, there should be only one card
which successfully sends its full CID-number to
the host. This card then goes into Identification
State. The host issues CMD3,
(SET_RELATIVE_ADDR) to assign this card a
relative address (RCA), which is shorter than
CID and which will be used to address the card in
future data transfer mode communication
(typically with a higher clock rate than fOD).
Once the RCA is received the card transfers to th e
Stand-by State and does not react to further
identification cycles. The MultiMediaCard also
switches its output drivers from open-drain to
push-pull.
The host repeats the identification process as long
as it receives a response (CID) to its identification
command (CMD2). When no MultiMediaCard
responds to this command, all cards have been
identified. The time-out condition to recognize
completion is the absence of a start bit for more
than 5 clock periods after sending CMD2.
5.3Data Transfer Mode
When all cards are in Stand-by State
communication over the CMD and DAT lines will
be in push-pull mode. Until the content of all CSD
registers is known by the host, the fPP clock rate
must remain at fOD because some cards may have
operating frequency restrictions. The host issues
SEND_CSD (CMD9) to obtain the Card Specific
Data (CSD register), e.g. ECC type, block length,
card storage capacity, maximum clock rate, etc.
Figure 5-2 MultiMediaCard State Diagram (Data Transfer Mode)
CMD7 is used to select one MultiMediaCard and
place it in the Transfer State. Only one
MultiMediaCard can be in the Transfer State at agiven time. If a previously selected
MultiMediaCard is in the Transfer State, its
connection with the host is released and it will
move back to the Stand-by State. When CMD7 i s
issued with the reserved relative card address
“0x0000,” all cards transfer back to Stand-by
State. This command is used to identify new cards
without resetting other already acquired cards.
MultiMediaCards which already have an RCA
do not respond to the identification command flow
in this state.
All data communication in the Data Transfer
Mode is point-to point between the host and th e
selected MultiMediaCard (using addressed
commands). All addressed commands are
acknowledged with a response on the CMD line.
Page 42
MultiMediaCard Product Manual
The relationship between the various data
transfer modes is summarized in the card state
diagram Figure 5-2, and in the following
paragraphs:
• All data read commands can be aborted
any time by the stop command (CMD12).
The data transfer will terminate and the
MultiMediaCard will return to t h e
Transfer State. The read commands are:
stream read (CMD11), block read
(CMD17), multiple block read (CMD18)
and send write protect (CMD30).
•All data write commands can be aborted
any time by the stop command (CMD12).
The write commands must be stopped prior
to deselecting the MultiMediaCard by
CMD7. The write commands are: stream
write (CMD20), block write (CMD24 and
CMD25), write CID (CMD26), and write
CSD (CMD27).
•If a stream write operation is stopped
prior to reaching the block boundary and
partial blocks are allowed (as defined in
the CSD), the part of the last block will
be packed as a partial block and
programmed. If partial blocks are not
allowed, the data will be discarded.
•As soon as the data transfer is completed,
the MultiMediaCard will exit the data
write state and move either to t h e
Programming State (transfer is successful)
or Transfer State (transfer failed).
•If a block write operation is stopped and
the block length and CRC of the last block
are valid, the data will be programmed.
•If data transfer in stream write mode i s
stopped, not byte aligned, the bits of the
incomplete byte are ignored and not
programmed.
•The MultiMediaCard may provide
buffering for stream and block write. This
means that the next block can be sent to
the card while the previous is being
programmed. If all write buffers are full,
and as long as the MultiMediaCard is in
Programming State (see MultiMediaCard
state diagram Figure 5-2), the DAT line
will be kept low.
•There is no buffering option for write CSD,
write CID, write protection and erase.
This means that while the
MultiMediaCard is busy servicing any one
of these commands, no other data transfer
commands will be accepted. DAT line will
be kept low as long as t h e
MultiMediaCard is busy and in t h e
Programming State.
•Parameter set commands are not allowed
while the MultiMediaCard is
programming. Parameter set commands
are: set block length (CMD16), and erase
tagging/untagging (CMD32-37).
•Read commands are not allowed while the
MultiMediaCard is programming.
•Moving another MultiMediaCard from
Stand-by to Transfer State (using CMD7)
will not terminate a programming
operation. The MultiMediaCard will
switch to the Disconnect State and will
release the DAT line.
•A MultiMediaCard can be reselected
while in the Disconnect State, using
CMD7. In this case the MultiMediaCard
will move to the Programming State and
reactivate the busy indication.
•Resetting a MultiMediaCard (using CMD0
or CMD15) will terminate any pending or
active programming operation. This may
destroy the data contents on t he
MultiMediaCard. It is up to the host’s
responsibility to prevent this.
5.3.1Data Read Format
The DAT bus line is high when no data is
transmitted. A transmitted data block consists of a
start bit (LOW), followed by a continuous data
stream. The data stream contains the net payload
data (and error correction bits if an off-card ECC is
used). The data stream ends with an end bi t
(HIGH). The data transmission is synchronous to
the clock signal.
The payload for block oriented data transfer is
preserved by a CRC check sum. The generator
polynomial is a standard CCITT polynomial
x16+x12+x5+1.
The code is a shortened BCH code with d=4 and is
used for payload length of up to 2048 Bytes.
There is a stream oriented data transfer controlled
by READ_DAT_UNTIL_STOP (CMD11). This
command instructs the card to send its payload,
starting at a specified address, until the host
sends a STOP_TRANSMISSION command
(CMD12). Note that the host stop command ha s
an execution delay due to the serial command
transmission. The data transfer stops after the end
bit of the STOP_TRANSMISSION command.
If the end of the memory range is reached while
sending data and no stop command has yet been
sent by the host, the content of the further
transferred payload is undefined.
The maximum clock frequency for stream read
operation is given by the following formula:
max. speed = min (TRAN_SPEED, (8*2
READ_BL_LEN
– NSAC)/TAAC)
1
If the host attempts to use a higher frequency, th e
card may not be able to sustain data transfer.
Should this happen, the card will set the
UNDERRUN error bit in the status register, abort
the transmission and wait in the data state for a
stop or a new read command.
•Block read
Block read is similar to stream read, except the
basic unit of data transfer is a block whose
maximum size is defined in the CSD
(READ_BL_LEN). Smaller blocks whose starting
and ending address are wholly contained within
one physical block (as defined by
READ_BL_LEN) may also be transmitted. Unlike
stream read, a CRC is appended to the end of each
block ensuring data transfer integrity. CMD17
(READ_SINGLE_BLOCK) starts a block read and
after a complete transfer the card goes
back to Transfer State. CMD18
(READ_MULTIPLE_BLOCK) starts a transfer of
several consecutive blocks. Blocks will be
continuously transferred until a stop command i s
issued.
If the host uses partial blocks whose accumulated
length is not block aligned, the card will, at the
beginning of the first misaligned block, detect a
block misalignment error, set th e
ADDRESS_ERROR error bit in the status register,
abort transmission and wait (in the Data State) for
a stop command.
1)All upper case names are defined in the CSD.
5.3.2Data Write Format
The data transfer format is similar to the data
read format. For block oriented write data
transfer, the CRC check bits are added to each
data block. The card performs a CRC check for
each such received data block prior to a write
operation. (The polynomial is the same one used
for a read operation.) By this mechanism, writing
of erroneously transferred data can be prevented.
•Stream write
Stream write (CMD20) means that data is
transferred beginning from the starting address
until the host issues a stop command. The data
stream must start and stop on block boundaries.
Since the amount of data to be transferred is not
determined in advance, CRC can not be used. If th e
end of the memory range is reached while sending
data and no stop command has been sent by t h e
host, the content of the further transferred
payload is discarded.
The maximum clock frequency for stream write
operation is given by the following formula:
max. speed = min (TRAN_SPEED, (8*2
WRITE_BL_LEN
– NSAC)/(TAAC*R2W_FACTOR))
If the host attempts to use a higher frequency, th e
card may not be able to process the data and will
stop programming, set the OVERRUN error bit in
the status register, and while ignoring all further
data transfer, wait (in the Receive-Data-State) for a
stop command. The write operation will also be
aborted if the host tries to write over a write
protected area. In this case, however, the card
will set the WP_VIOLATION bit.
•Block Write
Block write (CMD24 - 27) means that one or more
blocks of data are transferred from the host to the
card with a CRC appended to the end of each
block by the host. If the CRC fails, the card will
indicate the failure on the DAT line (see below);
the transferred data will be discarded and not
written and all further transmitted blocks (in
multiple block write mode) will be ignored.
If the host uses partial blocks whose accumulated
length is not block aligned, the card will detect
the block misalignment error and abort
programming before the beginning of the first
misaligned block. The card will set th e
ADDRESS_ERROR error bit in the status register,
and while ignoring all further data transfer, wait
(in the Receive-Data-State) for a stop command.
The write operation will also be aborted if t he
host tries to write over a write protected area. In
this case, however, the card will set t h e
WP_VIOLATION bit.
Programming of the CSD register does not require
a previous block length setting. The transferred
data is also CRC protected. Only the least
significant 16 bits of the CSD can be changed by
the host. The rest of the CSD register content must
match the card CSD. If the card detects content
inconsistency between the old and new CS D
register, it will not reprogram the CSD. This is
done to ensure validity of the CRC field of the
CSD register.
After receiving a block of data and completing th e
CRC check, the card will begin programming and
hold the DAT line low if its write buffer is full
and unable to accept new data from a new
WRITE_BLOCK command. The host may poll the
status of the card with a SEND_STATUS
command at any time, and the card will respond
with its status. The status bit
READY_FOR_DATA indicates whether t he
MultiMediaCard can accept new data or whether
the write process is still in progress. The host may
deselect the card by issuing CMD7 (to select a
different card) which will place the card in t h e
Disconnect State and release the DAT line
without interrupting the write operation. When
reselecting the card, it will reactivate busy
indication by pulling DAT to low if programming
is still in progress and write buffer is unavailable.
erase. After a range is selected, an individual
sector (or group) within that range can be removed
using the UNTAG command.
The host must adhere to the following
command sequence: TAG_SECTOR_START,
TAG_SECTOR_END, UNTAG_SECTOR (up to 16
untag sector commands can be sent for one erase
cycle) and ERASE (or the same sequence for group
tagging). The following exception conditions are
detected by the MultiMediaCard:
• An erase or tag/untag command is received
out of sequence. The card will set th e
ERASE_SEQ_ERROR error bit in t h e
status register and reset the whole
sequence.
• An out of sequence command (except
SEND_STATUS) is received. The card
will set the ERASE_RESET status bit in
the status register, reset the erase
sequence and execute the last command.
If the erase range includes write protected sectors,
they will be left intact and only the non protected
sectors will be erased. The WP_ERASE_SKIP
status bit in the status register will be set.
The address field in the tag commands is a sector
or a group address in byte units. The card will
ignore all LSBs below the group or sector size.
The number of untag commands (CMD34 and
CMD37) which are used in a sequence is limited up
to 16.
As described above for block write, th e
MultiMediaCard will indicate that an erase is in
progress by holding DAT low.
•Erase
It is desirable to erase many sectors
simultaneously in order to enhance the data
throughput. Identification of these sectors is
accomplished with the TAG_* commands. Either
an arbitrary set of sectors within a single erase
group, or an arbitrary selection of erase groups
may be erased at one time, but not both together.
That is, the unit of measure for determining an
erase is either a sector or an erase group, but if a
sector, all selected sectors must lie within the
same erase group. To facilitate selection, a first
command with the starting address is followed by
a second command with the final address, and a l l
sectors within this range will be selected for
•Write Protect Management
Card data may be protected against either erase
or write by the write protection features. The
entire card may be permanently write protected by
the manufacturer or content provider by setting
the permanent or temporary write protect bits in
the CSD. Portions of the data may also be
protected (in units of WP_GRP_SIZE sectors as
specified in the CSD). The SET_WRITE_PROT
command sets the write protection of the
addressed write-protect group, and th e
CLR_WRITE_PROT command clears the write
protection of the addressed write-protect group.
The SEND_WRITE_PROT command is similar to
a single block read command. The card will send a
data block containing 32 write protection bits
(representing 32 write protect groups starting at
the specified address) followed by 16 CRC bits.
The address field in the write protect commands is
a group address in byte units. The card will ignore
all LSBs below the group size.
5.4Clock Control
The MultiMediaCard bus clock signal can be used
by the MultiMediaCard host to set the cards to
energy saving mode or to control the data flow (to
avoid under-run or over-run conditions) on the bus.
The host is allowed to lower the clock frequency or
shut it down.
There are a few restrictions the MultiMediaCard
host must follow:
•The bus frequency can be changed at any
time (under the restrictions of maximum
data transfer frequency, defined by the
MultiMediaCard and the identification
frequency).
•It is an obvious requirement that the clock
must be running for the MultiMediaCard
to output data or response tokens. After
the last MultiMediaCard bus transaction,
the host is required, to provide 8 (eight)
clock cycles for the card to complete t he
operation before shutting down the clock.
Following is a list of various
MultiMediaCard bus transactions:
•A command with no response. 8 clocks
after the host command end bit.
•A command with response. 8 clocks after
the card response end bit.
•A read data transaction. 8 clocks after the
end bit of the last data block.
•A write data transaction. 8 clocks after
the CRC status token.
•The host is allowed to shut down the clock
of a “busy” card. The MultiMediaCard
will complete the programming operation
regardless of the host clock. However, t h e
host must provide a clock edge for the card
to turn off its busy signal. Without a clock
edge the MultiMediaCard (unless
previously disconnected by a deselect
command -CMD7) will force the DAT line
down, permanently.
5.5Cyclic Redundancy Codes (CRC)
The CRC is intended for protecting
MultiMediaCard commands, responses and data
transfer against transmission errors on th e
MultiMediaCard bus. One CRC is generated for
every command and checked for every response on
the CMD line. For data blocks, one CRC per
transferred block is generated. The CRC i s
generated and checked as described in t h e
following.
CRC7—The CRC7 check is used for all commands,
for all responses except type R3, and for the CSD
and CID registers. The CRC7 is a 7 bit value and is
computed as follows:
generator polynomial: G(x) = x
M(x) = (first bit) * x
bit) * x
0
n
+ (second bit) * x
CRC[6...0] = Remainder [(M(x) * x7) / G(x)]
All CRC registers are initialized to zero. The first
bit is the most significant bit of the corresponding
bit string (of the command, response, CID or CSD).
The degree n of the polynomial is the number of
CRC protected bits decreased by one. The number
of bits to be protected is 40 for commands and
responses (n = 39), and 120 for the CSD and CID
(n = 119).
CRC16—The CRC16 is used for payload protection
in block transfer mode. The CRC check sum is a 16
bit value and is computed as follows:
generator polynomial G(x) = x
M(x) = (first bit) * x
bit) * x
0
n
+ (second bit)* x
CRC[15...0] = Remainder [(M(x) * x
16
+ x12 +x5 +1
16
) / G(x)]
n-1
+...+ (last
All CRC registers are initialized to zero. The first
bit is the first data bit of the corresponding block.
The degree n of the polynomial denotes t he
number of bits of the data block decreased by one.
For example, n = 4,095 for a block length of 512
bytes. The generator polynomial G(x) is a
standard CCITT poly-nomial. The code has a
minimal distance d=4 and is used for a payload
length of up to 2,048 bytes (n ≤ 16,383).
All commands are protected by CRC (cyclic
redundancy check) bits. If the addressed
MultiMediaCard’s CRC check fails, the card does
not respond and the command is not executed. The
MultiMediaCard does not change its state, and
COM_CRC_ERROR bit is set in the status
register.
Similarly, if an illegal command has been
received, a MultiMediaCard shall not change it s
state, shall not response and shall set th e
ILLEGAL_COMMAND error bit in the status
register. Only the non-erroneous state branches are
shown in the state diagrams (Figure 5-1 and
Figure 5-2). Table 5-10 contains a complete state
transition description.
There are different kinds of illegal commands:
•Commands which belong to classes not
supported by the MultiMediaCard (e.g.
I/O command CMD39).
•Commands not allowed in the current state
(e.g. CMD2 in Transfer State).
•Commands which are not defined (e.g.
CMD6).
5.6.2Read, Write and Erase Time-out
Conditions
The times after which a time-out condition for
read/write/erase operations occurs are (card
independent) 10 times longer than the typical
access/program times for these operations given
below. A card shall complete the command within
this time period, or give up and return an error
message. If the host does not get a response within
the defined time-out it should assume the card is
not going to respond any more and try to recover
(e.g. reset the card, power cycle, reject, etc.). The
typical access and program times are defined as
follows:
Read
The read access time is defined as the sum of t h e
two times given by the CSD parameters TAAC
and NSAC. These card parameters define the
typical delay between the end bit of the read
command and the start bit of the data block. This
number is card dependent and should be used by
the host to calculate throughput and the maximal
frequency for stream read.
Write
The R2W_FACTOR field in the CSD is used to
calculate the typical block program time
obtained by multiplying the read access time by
this factor. It applies to all write/erase
commands (e.g. SET(CLEAR)_WRITE_PROTECT,
PROGRAM_CSD(CID) and the block write
commands). It should be used by the host to
calculate throughput and the maximal frequency
for stream write.
Erase
The duration of an erase command will be (order of
magnitude) the number of sectors to be erased
multiplied by the block write delay.
5.7Commands
5.7.1Command Types
There are four kinds of commands defined on th e
MultiMediaCard bus:
•Broadcast commands (bc)—sent on CMD,
no response
•Broadcast commands with response
(bcr)—sent on CMD, response (all cards
simultaneously) on CMD
•Addressed (point-to-point) commands
(ac)—sent on CMD, response on CMD
•Addressed (point-to-point) data transfer
commands (adtc)—sent on CMD, response
on CMD, data transfer on DAT
The command transmission always starts with th e
MSB.
Commands and arguments are listed in Table 5-3 through Table 5-9.
7-bit CRC Calculation: G(x) = x
M(x) = (start bit)∗x39 + (host bit)∗x38 +...+ (last bit before CRC)∗x
7 + x3 +
1
0
CRC[6...0] = Remainder[(M(x)∗x7)/G(x)]
5.7.3Command Classes
The command set of the MultiMediaCard is divided into several classes (See Table 5-2). Each class
supports a set of MultiMediaCard functions.
The supported Card Command Classes (CCC) are coded as a parameter in the card specific data (CSD)
register of each card, providing the host with information on how to access the card.
Table 5-2 Card Command Classes (CCCs)
Card
Command
Class (CCC)
Class DescriptionSupported Commands
1
end bit
0 1 2 3 4 7 9 10 11 12 13 15 16 17 18 20
Class 0Basic+ + + + + + + ++ + +
Class 1Stream Read+
Class 2Block Read+ + +
Class 3Stream Write+
Class 4Block Write+
Class 5Erase
Class 6Write Write-Protection
Class 7Read Write-Protection
Class 8Erase Write-Protection
Class 9I/O Mode
Class 10-11Reserved
2
1)7-bit Cyclic Redundancy Check.
2)I/O mode class is not supported by the SanDisk MultiMediaCard.
R1SET_BLOCKLENSelects a block length (in bytes) for all
length
CMD17adtc[31:0] data
address
CMD18adtc[31:0] data
address
R1READ_SINGLE_
BLOCK
R1READ_MULTIPLE_BL
OCK
CMD19Reserved
Table 5-5 Sequential Write Commands (Class 3)
Cmd
Index
CMD20adtc[31:0] data
CMD21.
..
CMD23
TypeArgumentRespAbbreviationCommand Description
R1WRITE_DAT_UNTIL_
address
STOP
Reserved
Table 5-6 Block Oriented Write Commands (Class 4)
Cmd
Index
TypeArgumentRespAbbreviationCommand Description
following block commands (read and
Reads a block of the size selected by the
SET_BLOCKLEN command.
write).
1
2
Continuously send blocks of data until
interrupted by a stop or a new read
command.
Writes data stream from the host starting
at the supplied address, until a
STOP_TRANSMISSION follows.
CMD24adtc[31:0] data
address
CMD25adtc[31:0] data
address
R1WRITE_BLOCKWrites a block of the size selected by the
SET_BLOCKLEN command.
R1WRITE_MULTIPLE_
BLOCK
Continuously writes blocks of data until a
STOP_TRANSMISSION follows.
3
CMD26Not Applicable
CMD27adtc[31:0] don’t cares* R1PROGRAM_CSDProgramming of the programmable bits of
the CSD.
*Note: The bit places must be filled but the value is irrelevant.
1)The default block length is as specified in the CSD (512 bytes). A set block length of less than 512 bytes will
cause a write error. The only valid write set block length is 512 bytes. CMD16 is not mandatory if the default is
accepted.
2)The data transferred must not cross a physical block boundary.
3)All data blocks are responded to with a data response token followed by a busy signal. The data transferred
must not cross a physical block boundary.
All responses are sent via the CMD line. The response transmission always starts with the MSB. The
response length depends on the response type.
A response always starts with a start bit (always ‘0’), followed by the bit indicating the direction of
transmission (card = ‘0’). A value denoted by ‘x’ in the tables below indicates a variable entry. A l l
responses except for the type R3 (see below) are protected by a CRC. Every response is terminated by th e
end bit (always ‘1’).
There are five types of responses. Their formats are defined as follows:
R1 (standard response): response length 48 bit.
Bits 45:40 indicate the index of the command which is responded to.The status of the card is coded in 32
bits.
Bit Position4746[45:40][39:8][7:1]0
Width (bits)1163271
Value‘0’‘0’xxx‘1’
Description start bittransmission bitcommand indexcard statusCRC7end bit
R1b is identical to R1 with the additional busy signaling via the data.
R2 (CID, CSD register): response length 136 bits.
The content of the CID register is sent as a response to CMD2 and CMD10. The content of the CSD
register is sent as a response to CMD9. Only bits [127...1] of the CID and CSD are transferred, bit [0] of
these registers is replaced by the end bit of the response.
Bit Position135134[133:128][127:1]0
Width (bits)1161271
Value‘0’‘0’‘111111’x‘1’
Description start bittransmission bitreservedCID or CSD register incl.
internal CRC7
end bit
R3 (OCR register): response length 48 bits.
The contents of the OCR register is sent as a response to CMD1.
Bit Position4746[45:40][39:8][7:1]0
Width (bits)1163271
Value‘0’‘0’‘111111’x‘1111111’‘1’
Description start bittransmission bitreservedOCR registerreservedend bit
All timing diagrams use the following schematics and abbreviations:
Table 5-11 Timing Diagram Symbols
SStart Bit (= 0)
TTransmitter Bit (Host = 1, Card = 0)
POne-cycle Pull-up (= 1)
EEnd Bit (=1)
ZHigh Impedance State (-> = 1)
DData Bits
*Repeater
CRCCyclic Redundancy Check Bits (7 Bits)
Card Active
Host Active
The difference between the P-bit and Z-bit is that a P-bit is actively driven to HIGH by the card
respectively host output driver, while Z-bit is driven to (respectively kept) HIGH by the pull-up
resistors R
respectively R
CMD
. Actively-driven P-bits are less sensitive to noise superposition.
DAT
All timing values are defined in Table 5-12.
5.10.1 Command and Response
Both host command and card response are clocked out with the rising edge of the host clock. The
minimum delay between the host command and card response is NCR clock cycles. This timing diagram is
relevant for host command CMD3.
There is just one Z bit period followed by P bits pushed up by the responding card. This timing diagram
is relevant for all responded host commands except CMD1,2,3.
<---- Host Command ---->
CMDS TContentCRCE Z Z P
<-N
CR
Cycles->
* * *
<-------- Response --------->
P S TContentCRC EZZZ
Figure 5-6 Command Response Timing (Data Transfer Mode)
Card Identification and Card Operation Conditions Timing—The card identification (CMD2) and card
operation conditions (CMD1) timing are processed in the open-drain mode. The card response to the host
command starts after exactly NID clock cycles.
Last Card Response - Next Host Command Timing—After receiving the last card response, the host can
start the next command transmission after at least NRC clock cycles. This timing is relevant for any host
command.
<-------- Response -------->
CMDS TContentCRCE Z
<-N
RC
* * * * * *
Cycles ->
<---- Host Command ----->
Z S TContentCRC E
Figure 5-8 Timing Response End to Next CMD Start (Data Transfer Mode)
Last Host Command - Next Host Command Timing Diagram—After the last command has been sent,
the host can continue sending the next command after at least NCC clock periods. This timing is relevant
for any host command that does not have a response.
<----- Host Command ---->
CMDS TContentCRCE Z
Figure 5-9 Timing CMDn End to CMD
<-N
CC
* * * * * *
Cycles ->
<---- Host Command ----->
Z S TContentCRC E
Start (All Modes)
n+1
In the case the CMDn command was a last acquisition command no more responded by any card, than
the next CMD
command is allowed to follow after at least NCC +136 (the length of the R2 response)
n+1
clock periods.
5.10.2 Data Read
Single Block Read—The host selects one card for data read operation by CMD7, and sets the valid
block length for block oriented data transfer by CMD16. The basic bus timing for a read operation i s
given in Figure 5-10. The sequence starts with a single block read command (CMD17) which specifies
the start address in the argument field. The response is sent on the CMD line as usual.
DATZZZ * * * * ZZZZZZP* * * * * * * * * * P S D D D * * *
<-N
Cycles ->
CR
P * * *
<-------- NAC Cycles ------->
<-------- Response --------->
P S TContentCRC E
<- Read Data
Figure 5-10 Transfer of Single Block Read
Data transmission from the card starts after the access time delay NAC beginning from the end bit of
the read command. After the last data bit, the CRC check bits are suffixed to allow the host to check
for transmission errors.
Multiple Block Read—In multiple block read mode, the card sends a continuous flow of data blocks
following the initial host read command. The data flow is terminated by a stop transmission command
(CMD12). Figure 5-11 describes the timing of the data blocks and Figure 5-12 the response to a stop
command. The data transmission stops two clock cycles after the end bit of the stop command.
Figure 5-12 Timing of Stop Command (CMD12, Data Transfer Mode)
Stream Read—The data transfer starts NAC clock cycles after the end bit of the host command. The bus
transaction is identical to that of a read block command (see Figure 5-10). As the data transfer is not
block oriented, the data stream does not include the CRC checksum. Consequently, the host can not
check for data validity. The data stream is terminated by a stop command. The corresponding bus
transaction is identical to the stop command for the multiple read block (see Figure 5-12).
5.10.3Data Write
Single Block Write—The host selects one card for
a data write operation by CMD7.
The host sets the valid block length for block
oriented data transfer (a stream write mode is
also available) by CMD16.
The data transfer from the host starts NWR clock
cycles after the card response was received.
The data is suffixed with CRC check bits to allow
the card to check it for transmission errors. The
card sends back the CRC check result as a CRC
status token on the data line. In the case of
The basic bus timing for a write operation is given
in Figure 5-13. The sequence starts with a single
block write command (CMD24) which determines
(in the argument field) the start address. It is
responded by the card on the CMD line as usual.
transmission error the card sends a negative CRC
status (‘101’). In the case of non erroneous
transmission the card sends a positive CRC status
(‘010’) and starts the data programming
procedure.
If the MultiMediaCard does not have a free data receive buffer, the card indicates this condition by
pulling down the data line to LOW. The card stops pulling down the data line as soon as at least one
receive buffer for the defined data transfer block length becomes free. This signaling does not give any
information about the data write status which must be polled by the host.
Multiple Block Write—In multiple block write mode, the card expects continuous flow of data blocks
following the initial host write command. The data flow is terminated by a stop transmission command
(CMD12). Figure 5-14 describes the timing of the data blocks with and without card busy signal.
Figure 5-14 Timing of Multiple Block Write Command
In write mode, the stop transmission command works similarly to the stop transmission command in t h e
read mode. Figures 5-15 to 5-18 describe the timing of the stop command in different card states.
Figure 5-15 Stop Transmission During Data Transfer from the Host
The card will treat a data block as successfully received and ready for programming only if the CRC
data of the block was validated and the CRC status token sent back to the host. Figure 5-16 is an
example of an interrupted (by a host stop command) attempt to transmit the CRC status block. The
sequence is identical to all other stop transmission examples. The end bit of the host command i s
followed, on the data line, with one more data bit, end bit and two Z clock for switching the bus
direction. The received data block, in this case is considered incomplete and will not be programmed.
Figure 5-16 Stop Transmission During CRC Status Transfer from the Card
All previous examples dealt with the scenario of the host stopping the data transmission during an
active data transfer. The following two diagrams describe a scenario of receiving the stop transmission
between data blocks. In the first example the card is busy programming the last block while in the
second the card is idle. However, there are still unprogrammed data blocks in the input buffers. These
blocks are being programmed as soon as the stop transmission command is received and the card
activates the busy signal.
Figure 5-17 Stop Transmission Received After Last Data Block. Card is Busy Programming.
Figure 5-18 Stop Transmission Received After Last Data Block. Card Becomes Busy.
Stream Write—The data transfer starts NWR clock cycles after the card response to the sequential write
command was received. The bus transaction is identical to that of a write block command (see
Figure 5-13). As the data transfer is not block oriented, the data stream does not include the CRC
checksum. Consequently the host can not receive any CRC status information from the card. The data
stream is terminated by a stop command. The bus transaction is identical to the write block option when
a data block is interrupted by the stop command (see Figure 5-15).
Erase, Set and Clear Write Protect Timing—The host must first tag the sectors to erase using the tag
commands (CMD32 - CMD37). The erase command (CMD38), once issued, will erase all tagged sectors.
Similarly, set and clear write protect commands start a programming operation as well. The card will
signal “busy” (by pulling the DAT line low) for the duration of the erase or programming operation. The
bus transaction timings are described in Figure 5-18.
While the MultiMediaCard channel is based on
command and data bit-streams which are
initiated by a start bit and terminated by a stop
bit, the SPI channel is byte oriented. Every
command or data block is built of 8 bit bytes and is
byte aligned (multiples of 8 clocks) to the CS
signal.
Similar to the MultiMediaCard protocol, the SPI
messages are built from command, response and
data-block tokens. All communication between
host and cards is controlled by the host (master).
The host starts every bus transaction by asserting
the CS signal low.
The response behavior in SPI mode differs from
the MultiMediaCard mode in the following three
aspects:
• The selected card always responds to t h e
command.
• An 8 or 16 bit response structure is used.
• When the card encounters a data retrieval
problem, it will respond with an error
response (which replaces the expected
data block) rather than time-out as in the
MultiMediaCard mode.
Only single block read write operations are
supported in SPI mode. In addition to the
command response, every data block sent to th e
card during write operations will be responded
with a special data response token. A data block
may be as big as one card sector and as small as a
single byte.
6.1.1Mode Selection
The MultiMediaCard wakes up in the
MultiMediaCard mode. It will enter SPI mode i f
the CS signal is asserted (negative) during t h e
reception of the reset command (CMD0). If the
card recognizes that the MultiMediaCard mode is
1
1)The default block length is as specified in the CSD
(512 bytes). A set block length of less than 512
bytes will cause a write error. The only valid write
set block length is 512 bytes. CMD16 is not
mandatory if the default is accepted.
required it will not respond to the command and
remain in the MultiMediaCard mode. If SPI mode
is required, the card will switch to SPI mode and
respond with the SPI mode R1 response.
The only way to return to the MultiMediaCard
mode is by power cycling the card. In SPI mode,
the MultiMediaCard protocol state machine is not
observed. All the MultiMediaCard commands
supported in SPI mode are always available.
The CMD (pin 2) and DAT[0] (pin 7) lines start up
in “Open Drain”2 mode and must be sourced
externally. Once the card is in SPI mode, the lines
are in “push-pull” mode until power is cycled.
Since the card defaults to MultiMediaCard mode
after a power cycle, Pin 1 (CS) must be pulled low
and CMD0 (40h) must be sent on the CMD (DataIn,
pin 2) line in order for the card to enter SPI mode.
The default command structure/protocol for
MultiMediaCard mode is to have CRC checking
enabled.
The default command structure/protocol for SPI
mode is that CRC checking is disabled. Since th e
card powers up in MultiMediaCard mode, CMD0
must be followed by a valid CRC byte (even
though the command is sent using the SPI
structure). Once in SPI mode, CRCs are disabled by
default.
CMD0 is a static command and always generates
the same 7 bit CRC of 4Ah. Adding the “1,” end
bit (bit 0) to the CRC creates a CRC byte of 95h.
The following hexidecimal sequence can be used to
send CMD0 in all situations for SPI mode, since
the CRC byte (although required) is ignored once
in SPI mode. The entire CMD0 sequence appears as
40 00 00 00 00 95 (hexidecimal).
Every MultiMediaCard token transferred on t he
bus is protected by CRC bits. In SPI mode, th e
MultiMediaCard offers a non protected mode
which enables systems built with reliable data
links to exclude the hardware or firmware
required for implementing the CRC generation and
verification functions.
In the non protected mode the CRC bits of th e
command, response and data tokens are still
required in the tokens however, they are defined
as “don’t cares” for the transmitters and ignored
by the receivers.
From
Host to
Card
From
Card to
Host
The SPI interface is initialized in the non
protected mode. The host can turn this option on
and off using CRC_ON_OFF command (CMD59).
The CRC7/CRC16 polynomials are identical to
that used in MultiMediaCard mode. Refer to this
section in the MultiMediaCard mode chapter.
6.1.3Data Read
SPI mode supports single block read operation only
(MultiMediaCard CMD17). Upon reception of a
valid read command the card will respond with a
response token followed by a data token in t h e
length defined in a previous
SET_BLOCK_LENGTH (CMD16) command (refer
to Figure 6-1).
Data From
Card to Host
Next
Command
DataIn
DataOut
Command
Response
Figure 6-1 Read Operation
A valid data block is suffixed with a 16 bit CRC
generated by the standard CCITT polynomial:
x16+x12+x5+1.
The maximum block length is 512 bytes as defined
by READ_BL_LEN (CSD parameter). Block
lengths can be any number between 1 and
READ_BL_LEN
From
Host to
Card
DataIn
Command
From
Card to
Host
Command
Data BlockCRC
The start address can be any byte address in the
valid address range of the card. Every block,
however, must be contained in a single physical
card sector.
In case of data retrieval error, the card will not
transmit any data. Instead, a special data error
token will be sent to the host. Figure 6-2 shows a
data read operation which terminated with an
error token rather than a data block.
As for the read operation, while in SPI mode the MultiMediaCard supports single block write only.
Upon reception of a valid write command (MultiMediaCard CMD24) the card will respond with a
response token and will wait for a data block to be sent from the host. CRC suffix and start address
restrictions are identical to the read operation (refer to Figure 6-3). The only valid block length,
however, is 512 bytes. Setting a smaller block length will cause a write error on the next write
command.
From
Host to
Card
DataIn
DataOut
From
Card to
Host
Command
Response
Data From
Host to Card
Figure 6-3 Write Operation
After a data block is received the card will
respond with a data-response token and if t h e
data block is received with no errors it will be
programmed. As long as the card is busy
programming, a continuous stream of busy tokens
will be sent to the host (effectively holding t he
dataOut line low).
Once the programming operation is completed, t h e
host must check the results of the programming
using the SEND_STATUS command (CMD13).
Some errors (e.g. address out of range, write
protect violation, etc.) are detected during
programming only. The only validation check
performed on the data block and communicated to
the host via the data-response token is CRC.
Resetting the CS signal while the card is busy,
will not terminate the programming process. The
card will release the dataOut line (tristate) and
continue to program. If the card is reselected
Data
Response
New Command
From Host
and Busy
From Card
CommandData Block
Data_Response Busy
before the programming is done, the dataOut line
will be forced back to low and all commands will
be rejected.
Resetting a card (using CMD0) will terminate any
pending or active programming operation. This
may destroy the data formats on the card. It is th e
host’s responsibility to prevent it.
6.1.5Erase & Write Protect Management
The erase and write protect management
procedures in the SPI mode are identical to t h e
MultiMediaCard mode. While the card is erasing
or changing the write protection bits of th e
predefined sector list it will be in a busy state and
will hold the dataOut line low. Figure 6-4
illustrates a “no data” bus transaction with and
without busy signaling.
Unlike the MultiMediaCard protocol (where the
register contents are sent as a command response),
reading the contents of the CSD and CID registers
in SPI mode is a simple read-block transaction.
The card will respond with a standard response
token followed by a data block of 16 bytes suffixed
with a 16 bit CRC.
6.1.7Reset Sequence
The MultiMediaCard requires a defined reset
sequence. After power on reset or CMD0 (software
reset) the card enters an idle state. Note that a t
least 74 clock cycles are required prior to starting
bus communication. At this state the only legal
host command is CMD1 (SEND_OP_COND). In
SPI mode, however, CMD1 has no operands.
The host must poll the card (by repeatedly
sending CMD1) until the ‘in-idle-state’ bit in th e
card response indicates (by being set to 0) that the
card completed its initialization processes and i s
ready for the next command.
6.1.8Clock Control
The SPI bus clock signal can be used by the SPI
host to set the cards to energy saving mode or to
control the data flow (to avoid under-run or overrun conditions) on the bus. The host is allowed to
change the clock frequency or shut it down.
There are a few restrictions the SPI host must
follow:
• The bus frequency can be changed at any
time (under the restrictions of maximum
data transfer frequency, defined by the
MultiMediaCards).
• It is an obvious requirement that the clock
must be running for the MultiMediaCard
to output data or response tokens. After
the last SPI bus transaction, the host is
required to provide 8 (eight) clock cycles
for the card to complete the operation
before shutting down the clock.
Throughout this 8 clock period, the state
of the CS signal is irrelevant. It can be
asserted or deasserted. Following is a list
of the various SPI bus transactions:
• A command/response sequence. Eight
clocks after the card response end bit.
The CS signal can be asserted or
deasserted during these 8 clocks.
• A read data transaction. Eight clocks
after the end bit of the last data
block.
• A write data transaction. Eight clocks
after the CRC status token.
• The host is allowed to shut down the clock
of a “busy” card. The MultiMediaCard
will complete the programming operation
regardless of the host clock. However, t h e
host must provide a clock edge for the card
to turn off its busy signal. Without a clock
edge, the MultiMediaCard (unless
previously disconnected by deasserting
the CS signal) will force the dataOut line
down, permanently.
6.1.9 Error Conditions
6.1.9.1CRC and Illegal Command
All commands are optionally protected by CRC
(cyclic redundancy check) bits. If the addressed
MultiMediaCard’s CRC check fails, t h e
COM_CRC_ERROR bit will be set in the card’s
response. Similarly, if an illegal command h a s
been received, the ILLEGAL_COMMAND bit will
be set in the card’s response.
There are different kinds of illegal commands:
• Commands which belong to classes not
supported by the MultiMediaCard (e.g.
interrupt and I/O commands).
• Commands not allowed in SPI mode (e.g.
CMD20 – write stream).
• Commands which are not defined (e.g.
CMD6).
6.1.9.2Read, Write and Time-out Conditions
The times that a time-out condition for
read/write/erase operations occur are (card
independent) 10 times longer than the typical
access/program times for these operations given
below. A card will complete the command within
this time period or give up and return an error
message. If the host does not get a response within
the defined time-out, it should assume the card is
not going to respond any more and try to recover
(e.g. reset the card, power cycle, reject, etc.). The
typical access and program times are defined as
follows:
Read
The read access time is defined as the sum of t h e
two times given by the CSD parameters TAAC
and NSAC. These card parameters define the
typical delay between the end bit of the read
command and the start bit of the data block. This
number is card dependent and should be used by
the host to calculate throughput and t h e
maximum frequency for stream read.
6.2SPI Command Set
6.2.1Command Format
Write
The R2W_FACTOR field in the CSD is used to
calculate the typical block program time obtained
by multiplying the read access time by this factor.
It applies to all write/erase commands (e.g. SET
(CLEAR)_WRITE_PROTECT, PROGRAM_CSD
(CID) and the block write commands). It should be
used by the host to calculate throughput and th e
maximum frequency for stream write.
Erase
The duration of an erase command will be (order of
magnitude) the number of sectors to be erased
multiplied by the block write delay.
6.1.10 Memory Array Partitioning
Same as for MultiMediaCard mode.
All the MultiMediaCard commands are 6 bytes
long and transmitted MSB first.
Byte 1Bytes 2 - 5Byte 6
765031070
01CommandCommand ArgumentCRC1
Commands and arguments are listed in Table 6-4.
7-bit CRC Calculation: G(x) = x
M(x) = (start bit)∗x39 + (host bit)∗x38 +...+ (last bit before CRC)∗x
The following table provides a detailed
description of the SPI bus commands. The
responses are defined in section 6.2.2. This table
an argument, the value of this field should be set
to zero. The reserved commands are reserved in
MultiMediaCard mode as well.
below lists all MultiMediaCard commands. A
“yes” in the SPI mode column indicates that t h e
command is supported in SPI mode. With these
restrictions, the command class description in th e
CSD is still valid. If a command does not require
The binary code of a command is defined by the
mnemonic symbol. As an example, the content of
the Command field for CMD0 is (binary) ‘000000’
and for CMD39 is (binary) ‘100111.’
Table 6-1 Description of SPI Bus Commands
CMD
INDEX
CMD0YesNoneR1GO_IDLE_STATEResets the MultiMediaCard
CMD1YesNoneR1SEND_OP_CONDActivates the card’s initialization
CMD2No
CMD3No
CMD4No
CMD5reserved
CMD6reserved
CMD7No
SPI
Mode
ArgumentRes
p
AbbreviationCommand Description
process.
CMD8reserved
CMD9YesNoneR1SEND_CSDAsks the selected card to send its card-
specific data (CSD).
CMD10YesNoneR1SEND_CIDAsks the selected card to send its card
identification (CID).
CMD11No
CMD12No
CMD13YesNoneR2SEND_STATUSAsks the selected card to send its status
register.
CMD14No
CMD15No
CMD16Yes[31:0] block
length
CMD17Yes[31:0] data
address
R1SET_BLOCKLENSelects a block length (in bytes) for all
following block commands (read and
1
write).
R1READ_SINGLE_
BLOCK
Reads a block of the size selected by the
SET_BLOCKLEN command.
2
1)The only valid block length for write is 512 bytes. The valid block length for read is 1 to 512 bytes. A set block
length of less than 512 bytes will cause a write error. The card has a default block length of 512 bytes. CMD16 is
not mandatory if the default is accepted.
2)The start address and block length must be set so that the data transferred will not cross a physical block
WRITE_BLOCKWrites a block of the size selected by the
SET_BLOCKLEN command.
3
PROGRAM_CSDProgramming of the programmable bits of
the CSD.
4
CMD28Yes[31:0] data
address
CMD29Yes[31:0] data
address
CMD30Yes[31:0] write
protect data
address
CMD31reserved
CMD32Yes[31:0] data
address
CMD33Yes[31:0] data
address
CMD34Yes[31:0] data
address
CMD35Yes[31:0] data
address
R1bSET_WRITE_PROTIf the card has write protection features,
this command sets the write protection
bit of the addressed group. The
properties of write protection are coded in
the card specific data (WP_GRP_SIZE).
R1bCLR_WRITE_PROTIf the card has write protection features,
this command clears the write protection
bit of the addressed group.
R1SEND_WRITE_
PROT
R1TAG_SECTOR_
START
R1TAG_SECTOR_
END
If the card has write protection features,
this command asks the card to send the
status of the write protection bits.
5
Sets the address of the first sector of the
erase group.
Sets the address of the last sector in a
continuous range within the selected
erase group, or the address of a single
sector to be selected for erase.
R1UNTAG_SECTORRemoves one previously selected sector
from the erase selection.
R1TAG_ERASE_
GROUP_START
Sets the address of the first erase group
within a range to be selected for erase.
CMD36Yes[31:0] data
address
CMD37Yes[31:0] data
address
3)Data followed by data response plus busy.
4)The start address must be aligned on a sector boundary The block length is always 512 bytes.
5)32 write protection bits (representing 32 write protect groups starting at the specified address) followed by 16
CRC bits are transferred in a payload format via the data line.
Sets the address of the last erase group
within a continuous range to be selected
for erase.
Removes one previously selected erase
group from the erase selection.
Page 68
MultiMediaCard Product Manual
CMD38Yes[31:0] don’t cares* R1bERASEErases all previously selected sectors.
CMD39No
CMD40No
CMD41.
..
CMD58
reserved
CMD59Yes[31:1] don’t cares*
[0:0] CRC option
CMD60-63No
*Note: The bit places must be filled but the values are irrelevant.
R1CRC_ON_OFFTurns the CRC option on or off. A ‘1’ in the
6.2.2Responses
There are several types of response tokens. As in
the MultiMediaCard mode, all are transmitted
MSB first.
6.2.2.1 Format R1
This response token is sent by the card after every
command with the exception of SEND_STATUS
commands. It is 1 byte long, the MSB is always set
7
0
to zero and the other bits are error indications. A
‘1’ signals error.
The structure of the R1 format is given in
Figure 6-5.
• In idle state: The card is in idle state and
running initializing process.
• Erase reset: An erase sequence was cleared
before executing because an out of erase
sequence command was received.
6.2.2.2Format R1b
• Illegal command: An illegal command
code was detected.
This response token is identical to R1 format with
• Communication CRC error: The CRC check
of the last command failed.
• Erase sequence error: An error in t h e
sequence of erase commands occurred.
the optional addition of the busy signal. The busy
signal token can be any number of bytes. A zero
value indicates card is busy. A non zero value
indicates card is ready for the next command.
CRC option bit will turn the option on, a ‘0’
will turn it off
• Address error: A misaligned address,
which did not match the block length was
used in the command.
• Parameter error: The command’s argument
(e.g. address, block length) was out of t h e
allowed range for this card.
0
In Idle State
Erase Reset
Illegal Command
Com CRC Error
Erase_Seq_Error
Address Error
Parameter Error
This, 2 bytes long, response token is sent by th e
card as a response to the SEND_STATUS
command. The format of the R2 status is given in
Figure 6-6.
MultiMediaCard Product Manual
7
0
7
0
Figure 6-6 R2 Response Format
The first byte is identical to response R1. The
content of the second byte is described below:
• Erase param: An invalid selection, sectors
or groups, for erase.
• Write protect violation: The command
tried to write a write protected block.
• Card ECC failed: Card internal ECC was
applied but failed to correct the data.
• CC error: Internal card controller error.
• Error: A general or an unknown error
occurred during the operation.
• Write protect erase skip: Only partial
address space was erased due to existing
WP blocks.
0
0
WP Erase Skip
Error
CC Error
Card ECC Failed
WP Violation
Erase Param
Out of Range
In Idle State
Erase Reset
Illegal Command
Com CRC Error
Erase_Seq_Error
Address Error
Parameter Error
6.2.2.4Data Response
Every data block written to the card will be
acknowledged by a data response token. It is one
byte long and have the following format:
Read and write commands have data transfers
associated with them. Data is being transmitted
or received via data tokens. All data bytes are
transmitted MSB.
Data tokens are 4 to 515 bytes long and have the
following format:
• Byte 1: Start Byte
70
11111110
• Bytes 2-513 (depends on the data block
length): User data
• Last two bytes: 16 bit CRC.
6.2.4Data Error Token
If a read operation fails and the card cannot
provide the required data it will sent a data error
token, instead. This token is one byte long and has
the following format:
6.3Card Registers
In SPI Mode, only the MultiMediaCard, CSD and
CID registers are accessible. Their format is
identical to their format in the MultiMediaCard
mode. However, a few fields are irrelevant in SPI
mode.
7
00000
Error
CC_Error
Card_ECC_Failed
Out_of_Range
Figure 6-7 Data Error Token
The 4 LSBs are the same error bits as in response
format R2.
Call SanDisk Applications Engineering at 408-542-0405 for technical support.
SanDisk Worldwide Web Site
Internet users can obtain technical support and product information along with SanDisk news and much
more from the SanDisk Worldwide Web Site, 24 hours a day, seven days a week. The SanDisk
Worldwide Web Site is frequently updated. Visit this site often to obtain the most up-to-date
information on SanDisk products and applications. The SanDisk Web Site URL is
http://www.sandisk.com.
SanDisk warrants its products to be free of any defects in materials or workmanship that would prevent them from
functioning properly for one year from the date of purchase. This express warranty is extended by SanDisk
Corporation.
II. GENERAL PROVISIONS
This warranty sets forth the full extent of SanDisk’s responsibilities regarding the SanDisk MultiMediaCard. In
satisfaction of its obligations hereunder, SanDisk, at its sole option, will either repair, replace or refund the purchase
price of the product.
NOTWITHSTANDING ANYTHING ELSE IN THIS LIMITED WARRANTY OR OTHERWISE, THE EXPRESS
WARRANTIES AND OBLIGATIONS OF SELLER AS SET FORTH IN THIS LIMITED WARRANTY, ARE IN LIEU
OF, AND BUYER EXPRESSLY WAIVES ALL OTHER OBLIGATIONS, GUARANTIES AND WARRANTIES OF
ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED
WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR INFRINGEMENT,
TOGETHER WITH ANY LIABILITY OF SELLER UNDER ANY CONTRACT, NEGLIGENCE, STRICT LIABILITY
OR OTHER LEGAL OR EQUITABLE THEORY FOR LOSS OF USE, REVENUE, OR PROFIT OR OTHER
INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING WITHOUT LIMITATION PHYSICAL INJURY OR
DEATH, PROPERTY DAMAGE, LOST DATA, OR COSTS OF PROCUREMENT OF SUBSTITUTE GOODS,
TECHNOLOGY OR SERVICES. IN NO EVENT SHALL THE SELLER BE LIABLE FOR DAMAGES IN EXCESS OF
THE PURCHASE PRICE OF THE PRODUCT, ARISING OUT OF THE USE OR INABILITY TO USE SUCH
PRODUCT, TO THE FULL EXTENT SUCH MAY BE DISCLAIMED BY LAW.
SanDisk’s products are not warranted to operate without failure. Accordingly, in any use of products in life support
systems or other applications where failure could cause injury or loss of life, the products should only be incorporated
in systems designed with appropriate redundancy, fault tolerant or back-up features.
III. WHAT THIS WARRANTY COVERS
For products found to be defective within one year of purchase, SanDisk will have the option of repairing or replacing
the defective product, if the following conditions are met:
A. A warranty registration card for each defective product was submitted and is on file at SanDisk. If not, a
warranty registration card must accompany each returned defective product. This card is included in each
product’s original retail package.
B. The defective product is returned to SanDisk for failure analysis as soon as possible after the failure occurs.
C. An incident card filled out by the user, explaining the conditions of usage and the nature of the failure,
accompanies each returned defective product.
D. No evidence is found of abuse or operation of products not in accordance with the published specifications, or
of exceeding storage or maximum ratings or operating conditions.
All failing products returned to SanDisk under the provisions of this limited warranty shall be tested to the product’s
functional and performance specifications. Upon confirmation of failure, each product will be analyzed, by whatever
means necessary, to determine the root cause of failure. If the root cause of failure is found to be not covered by the
above provisions, then the product will be returned to the customer with a report indicating why the failure was not
covered under the warranty.
This warranty does not cover defects, malfunctions, performance failures or damages to the unit resulting from use in
other than its normal and customary manner, misuse, accident or neglect; or improper alterations or repairs.
SanDisk reserves the right to repair or replace, at its discretion, any product returned by its customers, even if such
product is not covered under warranty, but is under no obligation to do so.
SanDisk may, at its discretion, ship repaired or rebuilt products identified in the same way as new products, provided
such cards meet or exceed the same published specifications as new products. Concurrently, SanDisk also reserves the
right to market any products, whether new, repaired, or rebuilt, under different specifications and product
designations if such products do not meet the original product’s specifications.
According to SanDisk’s warranty procedure, defective product should be returned only with prior authorization from
SanDisk Corporation. Please contact SanDisk’s Customer Service department at 408-542-0595 with the following
information: product model number and description, serial numbers, nature of defect, conditions of use, proof of
purchase and purchase date. If approved, SanDisk will issue a Return Material Authorization or Product Repair
Authorization number. Ship the defective product to:
SanDisk Corporation
Attn: RMA Returns
(Reference RMA or PRA #)
140 Caspian Court
Sunnyvale, CA 94089
V. STATE LAW RIGHTS
SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL
DAMAGES, OR LIMITATION ON HOW LONG AN IMPLIED WARRANTY LASTS, SO THE ABOVE
LIMITATIONS OR EXCLUSIONS MAY NOT APPLY TO YOU. This warranty gives you specific rights and you may
also have other rights that vary from state to state.
VI. OUT OF WARRANTY REPAIRS
Please contact SanDisk Customer Service at 408-542-0595 for the current out of warranty and repair price list.