Mechanically MMC and SD cards are very small, with smaller compatible variants also available. They are low power and may be used with +3V3 systems. They use a serial interface based on the SPI specifications with fast transfer speeds possible (0-20MHz max clock rate for MMC, 0-25MHz max clock rate for SD) using only 4 pins. Data reliability is also provided by built-in defect management and error correction technologies. Whilst MMC and SD cards may also be communicated with using a 4 bit data interface this protocol is protected and not available without significant licence payments. The MMC card SPI interface protocol is available without any licence fee payable and is therefore more widely used than the 4 bit significantly more complex (and expensive!) protocol. SD cards are backwards compatible with the MMC card SPI interface and therefore this is typically the interface of choice for SD cards also. Note that the ‘Secure’ of Secure Digital, whilst available to licensed developers, is not widely used and you can just think of SD cards as a standard memory card in the same way as MMC cards (you do not need to implement security functionality to use them).

At the simplest level a MMC or SD card is just a large memory array which may be used in a similar way to a standard flash memory IC. Very simple applications may just use a MMC or SD card like any other memory device, storing data on it as required by the application. However this has the obvious limitation that the contents of the card is only readable and writable by the device that is using it. To allow other devices to easily read and write data to the card requires the use of a standardised file system. If a filing system is chosen that is also used by computers then sharing data with computer applications is made very simple.

There are 3 flavours of FAT (File Allocation Table):- FAT12, FAT16 and FAT32. FAT12 has now effectively become obsolete as the very small memory sizes of card this was useful for (<=16MB) are no longer generally available. This leaves FAT16 and FAT32. The 16 and 32 simply refer to the size of the cluster value in bits, although FAT32 is actually only 28 bits as 4 bits are reserved (see below for an explanation of clusters etc). This simply means that a FAT32 table takes up more space on a disk (or memory card), as each entry uses more bytes, but it allows addressing of larger memory sizes with smaller cluster sizes, resulting in less wastage of disk space. This use of smaller cluster sizes can quickly pay off in terms of efficiency as less space wastage at the end of each file frees up more space than the larger FAT32 table uses up.

Limits of FAT16

Maximum volume size is 2GB

Maximum file size is 2GB

Maximum number of files is 65,517

Maximum of 512 files or folders per folder

Limits of FAT32

Maximum volume size is 2TB

Maximum file size is 4GB

Maximum number of files is 268,435,437

Maximum of 65,534 files or folders per folder

You may think that you don’t need anything more than FAT16 for your application if you don’t plan to store more than 2GB of data on a MMC or SD card. After all, many embedded applications only need to store relatively small amounts of data. However MMC and SD cards with capacities greater than 256MB are typically supplied pre-formatted with FAT32. This is because FAT32 uses larger volumes more efficiently than FAT16 and is also less susceptible to a single point of failure due to the use of a backup copy of critical data structures in the boot record. Therefore if you use a driver that only supports FAT16 for your application your users will need to find a PC with a MMC or SD card adaptor to re-format larger capacity cards to be FAT16 before they can be used with your device. You also run the risk of increased technical support demands from users who haven’t read your instructions or don’t understand how to format a card as FAT16 instead of the default FAT32 and can’t work out why their new MMC or SD card won’t work in your device. Using a driver that supports FAT16 and FAT32 doesn’t result in a large amount of additional code space by today’s standards, as the two systems are very similar, and it makes life a lot easier for you and your users.

See the ‘Layout of a MMC or SD Card With FAT’ section later in this manual for detailed information of the FAT16 and FAT32 filing system.

The implementation and use of the FAT file system, the MMC and the SD specifications may require a license from various entities, including, but not limited to Microsoft® Corporation, IBM, SD Card Association and the MultiMediaCard Association. It is your responsibility to obtain information regarding any applicable licensing requirements.

Microsoft offers licensing for the use of its FAT filing system on a per unit sold basis. However it is generally viewed that this only applies to applications that implement the patented long file name system (LFN). It is our understanding that if long filenames are not used then no licence fee is due, however you should ascertain if you agree with this view yourself (to our knowledge Microsoft have not stated this but others have determined this based on original releases of the FAT standard by Microsoft).

IBM patents may also apply to technology supporting extended attributes within the file system.

Our understanding of the MMC and SD card licensing requirements are that no licence fee is payable if using the SPI bus mode as the required per card licence fee is paid by card manufacturers. However if you require legal clarification of this you should contact the relevant organisation yourself.

Card Capacities

This driver uses a buffer / block size of 512 bytes which is the standard block size supported by all MMC & SD cards. Some 2GB and 4GB SD cards provide a 1024 byte or 2048 byte block size as this was required prior to the release of V2.00 of the SD Physical Layer Specification. There is some confusion regarding this in relation to 2GB and 4GB SD cards. V1.01 of the SD specification allowed the original (V1.00) maximum block size of 512 bytes to be changed to 1024 or 2048 bytes, to deal with memory capacities of 2GB and 4GB. This lead to compatibility problems as host devices adhering to the V1.00 specification either did not recognise 2GB or 4GB cards, or would incorrectly interpret the card as 1GB and only access the first 1GB.

The issue is not to do with problems of being able to access data beyond 1GB using the actual read and write commands (which use a 32 bit address so have no problems), but is to do with the card identification data that a host uses to determine the capacity of a card. Due to the specification limiting the maximum sectors per cluster to 4096 and the number of blocks per cluster to 512, a buffer size of 512 bytes meant a limit of 1GB (4096 clusters x 512 blocks per cluster x 512 bytes per block). By changing the block size to 1024 or 2048 bytes card sizes of 2GB and 4GB can be specified in this identification data. However, although a card may specify that it has a maximum buffer size of 1024 or 2048 bytes there is no requirement to use it. This driver will correctly access 2GB and 4GB SD cards because it does not utilise the card identification data (it doesn’t need to as it doesn’t provide formatting) and because it specifies a block size of 512 bytes when initialising a card.

V2.00 of the SD specification addresses this problem and allows for higher card capacities. New SD cards of capacities greater that 2GB now use the SDHC standard, which allows for capacities of up to 2TB (although not all of this capacity is currently allowed under the official specification). It is also now specified that the block size must always be a maximum of 512 bytes to provide a common memory requirement and backwards compatibility. 2GB and 4GB SD cards may continue to specify to a host that they have a maximum block size of 1024 bytes or 2048 bytes, but to adhere to V2.00 they must not allow a block size of greater than 512 bytes to actually be used with the read and write commands.

Note that SDHC cards use an alternative addressing method that is not backwards compatible with SD cards, so although physically compatible a host needs to implement the new addressing in software to allow access to a SDHC card.

This driver supports the following cards (operating at the standard +3.3V):-

All standard SD cards (up to 4GB which is the maximum possible)

All standard SDHC cards

All standard MMC cards

All standard MMC Plus cards

Card Voltages

This driver is designed for standard +3.3V powered MMC and SD cards. Use of cards at other voltages may require additions to the driver to provide voltage compatibility checking.

Reduced Size Cards

The reduced size versions of the SD and MMC cards are electrically and software compatible. Only the physical size is different.

Formatting

This driver does not provide a format function. The reason for this is that formatting is complex and therefore code space heavy. All MMC and SD cards are supplied pre formatted so the inclusion of a format feature is not generally required.

Sub Directories

To avoid a significantly large code space requirement this driver supports reading and writing of files in a MMC or SD cards root directory only.

Long Filenames

This driver does not support long file names. Adding long filename support would use additional code space which is not desirable in many embedded applications, and is also subject to patent / licence restrictions / costs as Microsoft holds patents for the long filename specification. Files stored on a card using a long file name may still be accessed using their DOS equivalent short file name.

Using The Driver With a RTOS or Kernel

The stack / driver is implemented as a single thread so you just need to make sure it is always called from a single thread (it is not designed to be thread safe).

C18 Compiler Code & Data Size

The following are based on compiling the complete PIC18 demo project (including the driver) using the Microchip C18 compiler with all optimisations turned on.

Approximately 11522 program memory words (16 bit)

Approximately 799 bytes of RAM. This includes a continuous 512 byte buffer that is required by the driver (it is possible to share this buffer with other parts of an application – see the 512 Byte Buffer Define section of this manual).

An additional 22 bytes of static RAM are required for each file that may be opened simultaneously (set by the FFS_FOPEN_MAX define).

The driver requires a moderate amount of variable storage space from the stack for its functions.

C30 Compiler Code & Data Size

The following are based on compiling the complete PIC24 demo project (including the driver) using the Microchip C30 compiler with all optimisations set to smallest code size.

Approximately 5217 program memory words (24 bit)

Approximately 600 bytes of RAM. This includes a continuous 512 byte buffer that is required by the driver (it is possible to share this buffer with other parts of an application – see the 512 Byte Buffer Define section of this manual).

The driver requires a moderate amount of variable storage space from the stack for its functions.

MMC / SD Card Mode

The driver accesses a MMC or SD card using the licence free SPI mode.

The MMC and SD card SPI bus specifications are available from the following web sites:-

http://www.sdcard.org

http://www.mmca.org

If you need to read these specifications take care to ensure that you are reading the correct section of the specifications when dealing with SPI bus commands. The commands and responses used with the 4 bit parallel interface (not supported by this driver) are not exactly the same as the SPI based commands.