eMMC library

[Boomerang]

Is there any good library for reading/writing blocks from/to eMMC chip that will work on Cortex-M3 ? Is it one same library for SD cards and eMMC or they are separated ?

[Boomerang]

If it's the same - it should support 1, 4 and 8-bit bus, right? Where I can find such a library? What are you using for this purpose?

[Boomerang]

From Wikipedia:

The eMMC (embedded MMC[7]) architecture puts the MMC components (flash memory plus controller) into a small ball grid array (BGA) IC package for use in circuit boards as an embedded non-volatile memory system. This is noticeably different from other versions of MMC as this is not a user-removable card, but rather a permanent attachment to the circuit board. eMMC also does not support the SPI-bus protocol.

Is this true or it's outdated?

[Karel]

Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.

[Boomerang]

Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.

It will be connected only to my MCU. eMMC has so many advantages over the generic flash - it will take me years of coding and testing if I want to reach the same level of reliability with generic flash!

[Boomerang]

SD cards don't have ECC, bad block management, block refresh after read errors and etc....

[nctnico]

Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.

It will be connected only to my MCU. eMMC has so many advantages over the generic flash - it will take me years of coding and testing if I want to reach the same level of reliability with generic flash!

Why do you think that? Flash usually is single level cell so more reliable to begin with and if you store data in a circular way then you'll wear each flash cell equally. Implementing & testing this takes a few days (been there/done that). If you want to make it fancy you can do a write/verify and write the next piece of flash if the verify fails. If each record has a checksum then a valid checksum can be used to check whether the data is valid.

[Boomerang]

SD cards don't have ECC, bad block management, block refresh after read errors and etc....

Panasonic manufactures high-rel SD cards, along with microSD ones. Their MLC based devices are not too expensive (about 4x toe cost compared to consumer ones).

Even if I have hardware ECC - the rest of the block management will be up to me... I don't see any reason to write all this when it's already done and integrated into the eMMC controller.

[poorchava]

If eMMC doesn't support SPI,  then you'll need to use a CPU which has a hardware SDIO module. The SDIO protocol is proprietary,  much like MIPI DSI and CSI stuff. You need to pay membership fees to have access to documentation. It is possible though to implement communication using a hardware module without having the documentation. Can't tell you details, but I know for a fact that it can be done.

Sent from my HTC One M8s using Tapatalk.

[MT]

Sandisk also have a industrial  card, covering e.MMC 4.41 and e.MMC 4.51 HS200 specifications.

http://investor.sandisk.com/investor-relations/press-releases/press-release-details/2015/SanDisk-Introduces-New-Portfolio-of-Industrial-Grade-Flash-Storage-Solutions-for-the-Rapidly-Expanding-Industrial-Internet-of-Things-Market/default.aspx

http://panasonic.net/avc/sdcard/industrial_sd/

Embedded SDIO, simplified spec whatever that is..
https://www.sdcard.org/downloads/pls/index.html

[Boomerang]

If eMMC doesn't support SPI,  then you'll need to use a CPU which has a hardware SDIO module. The SDIO protocol is proprietary,  much like MIPI DSI and CSI stuff. You need to pay membership fees to have access to documentation. It is possible though to implement communication using a hardware module without having the documentation. Can't tell you details, but I know for a fact that it can be done.

it's a JEDEC standard available for download - if there is no good library for this - I will have to write my own.

[marshallh]

There is some confusion.


SD cards can be accessed either by SPI or the SD protocol (1/4bit) with its UHS-I/II extensions. You can implement the full SD protocol with completely accessible documentation (Simplified SD Spec 4.10 from the SD Association)

SDIO is a standard for interfacing periperals like network cards, cameras and card readers over the SD bus. It does not define the lower protocol, which is the SD protocol.


eMMC is basically a hard-wired SD card with functionality that is a superset of SD (which is itself a superset of original MMC). You should be able to access it with the same MCU peripheral you use to read a 4-bit SD card, or FPGA IP core.


Internally, these types of memory cards contain deceptively powerful 32bit ARM cores (typically) running a small RTOS that provides all manner of NAND babysitting like bad block mapping and on-demand reallocation (garbage collection). Modern MLC flash requires pretty complex error correction to even function -- the data stored on NAND is more like a stasticial approxmiation of what the data "should" be. BCH is basically the bare minimum to get meaningful data - which is probably done in software with some parts accelerated on die.

Lukcily you don't need to worry about all that, it's abstracted away by the controller on the memory. You just tell it "I'd like to read 26 sectors starting here" or "I'd like to write at least 60 sectors, so pre-erase them for me and then I'll send the data".
So, first talk to a normal SD card, then grab an emmc and take it from there.

[Boomerang]

OK, the question now turns to "is there some good library for working with SD cards over SD protocol?"

[Boomerang]

The main reason I'm planing to use eMMC is their capability to detect data retention errors and refresh the blocks when such errors are detected. I don't know any SD card capable doing this.

[nctnico]

A warning, implementing SD protocol requires SD patent license, despite it could be long expired if you use the oldest protocol.

If you implement MMC protocol, it is royalty free.

However, I would use a MCU with SDIO, and just use it, and fuck the patent.

I would assume the SDIO royalties are already paid because the MCU already has the interface.

[dgtl]

The SD cards must have ECC inside them; otherwise they would be unusable. Modern NAND flash chips require ECC to work at all (bit flips are part of "normal" operation). Even SLC flashes now require 4 bits correction capability, MLC and TLC flashes much more. Consumer-grade SD cards seem to lack proper wear levelling and die when some areas are written more.
There are enough industrial quality SD card vendors, even in micro-sd format. For example Swissbit, Panasonic, Apacer Industrial etc. If SD format is preferred, go for them. But the advantage of removable storage is the possibility of user swapping in whatever flash they want and that causes problems if they use inferior quality flashes. In these cases, reducing the functionality by having on-board flash is a good choice.

Driving an eMMC chip using microcontroller SDIO interface is not too difficult. The lower layers are the same (sending commands and payload data). Commandset-wise they are somewhat different (at least initialization). Download the eMMC spec (free) and just re-write the init commands. The spec may be frightening at first, but go for the state diagram and command code list for better overview. As the chip is soldered on board, you can probably avoid most of the auto-detection and just hardcode the geometry.

The eMMC has 8-bit interface, that is good for performance without getting clock rate too high. I've used eMMC flashes on STM32F2 uCs and the data rate was limited by the eMMC chip itself (we wrote the whole code ourself). When going for high-performance, read thoroughly the random-access specification of the eMMC chip. Linear bulk transport figures are specified for very large buffers (ie 1MB) and that is not available on uCs. You should see the random-access performance numbers, these are written as IOPS (read small print: IO operations per second for 4kB blocks). There is a large penalty of starting a new transfer and even for double-buffered 2x32kB blocks, you wont get near the linear transfer rate. But 200Mbit/s read rate is totally possible using ver 4.51 Micron chips.

On larger application processors, using eMMC instead of SD card is usually easier as the eMMC layer drivers in Linux and u-boot are already there and the SDIO controller does not care. Usually just designing the eMMC instead of SD socket works with very little effort.