eMMC ECC field?

Anyone here knowledgeable about eMMC memory?

I have a high reliability application where there is concern about memory corruption. What would happen if I changed the ECC field in the eMMC's Card Specific Data (CSD) register from the default no ECC to the optional BCH(542,512) encoding? Would I still be able to write/read new values to the eMMC normally with the eMMC internally protecting the contents with BCH ECC at the cost of reduced memory capacity, or would a special driver on the host be needed to encode/decode ECC reads/writes?

I've asked around and haven't found a definitive answer so far. Let me know if you can help ... Buzz

Reply to
Buzz McCool
Loading thread data ...

As I read an older version of the JEDEC standard, this field tells the host whether it needs to implement its own ECC logic in order to make sense of what's on the card (and how to update the data without corrupting it).

The eMMC may implement its own internal error-detection or error-correction codes. If so, these seem to be independent of the host-implemented ECC which is indicated by the CSD register.

It doesn't look to me as if changing this field has any effect on the card's internal operation.

Reply to
Dave Platt

Thanks Dave. Do you have a pointer to that JEDEC spec? I've been going off of JESD84-B50.

One thing that puzzles me is if this bit is just an indication to the host that it has to implement its own ECC logic, why would my JEDEC spec call out "BCH(542,512)" encoding? The JESD84-B50 also says things like:

"The shortened BCH (542,512) code was chosen for matching the requirement of having high efficiency at lowest costs."


"As the ECC blocks are not necessarily byte-aligned, bit stuffing is used to align the ECC blocks to byte boundaries. For the BCH (542,512) code, there are two stuff bits added at the end of the 542-bits block, leading to a redundancy of 5.9%."

I really appreciate your feedback ... Buzz

Reply to
Buzz McCool

The current version seems to be by-subscription-only. The one I was working from is an JEDS84-A43 which I think is even older than the one you found.

Here's how I understand it.

Basically, this field is just an format announcement - it tells you (the host) what's on the card, and what the conventions are for accessing it. Remember that the data may have been put onto the card by a different host that the one which is attempting to access it (e.g. think of eMMC modules being pre-formatted with a factory image, and then shipped to a customer and installed on customer-built boards).

Looking at this field tells a "compatible" host to do one of two things:

(1) Treat the data on the card as "all real data" - every 512-bit block read from the card has 512 bits of real user data.

(2) Treat the data on the card as "real user data, wrapped in host ECC of the BCH (542,512) variety). Every 68-byte block of data on the device (544 bits) consists of 542 bits of BCH (512 bits of payload, 30 bits of ECC) and 2 bits of padding. The host driver is responsible for translating its own read requests from "real data" address space, into the (larger-block) BCH address space, reading the BCH-encoded data, and performing the error correction.

The BCH error correction which has been selected for this purpose is just advisory. The host *could* choose to ignore the setting of the CSD bits entirely, and implement a completely different error-correction coding technique with different-sized blocks. The card itself wouldn't be aware of this... because the card really doesn't care about host-level ECC at all. However, if the host does this, then there's no standard way to set the CSD register to mean "Hey, I'm using this special ECC, not the recommended BCH coding" and thus this module would not be readable by another, standard-conforming host because it wouldn't know what ECC algorith to apply.

The host-provided ECC (whether it's the recommended BCH(542,512) or something else) is independent of whatever error detection/correction is being performed by the eMMC module's on-board controller.

Reply to
Dave Platt

Thanks so much for that very shrewd analysis.

Would you have any thoughts on implementing a eMMC BCH host driver?

I believe would first need to write to the CSD register to set the ECC bit. It didn't appear to me the Linux mmc-utils supported writing to the CSD register so I need to figure out how to do that myself.

The JESD84 state diagram shows there are multiple paths a "Write CSD" CMD27 can take to get back to a "Read CSD" CMD9 to be able to check if the CSD register now has the ECC bit set. I think the required sequence would be something like this:

CMD9 -> (Read CSD Register contents) CMD7 w/ RCA -> (Goto tran state) CMD27 -> (Write CSD register w/ changed ECC field and new CRC7) (?? Go back to tran state if transfer failed ??) (?? Go to prog state if transfer succeeds ??) (?? Go back to tran state when programming completes??) CMD7 w/ 0x0000 -> (Goto stby state) CMD9 -> (Reread CSD Register contents)

Since both a failed transfer and a successful programing both seem to lead back to the tran state, it is not clear to me how to tell if a CMD27 succeeds.

To get my feet wet with the eMMC state machine, I tried just reading the CSD register with CMD9, issuing a CMD7 with the assigned RCA to move to the Transfer State (trans) and then move back to the Standby State (stby).

CMD9 -> (Get CSD Register contents, Success!) CMD7 w/ RCA -> (Goto trans state) CMD13 -> (Verify in trans state, Success!) CMD7 w/ 0x0000 -> (Go back to stby state, Timeout Fail!)

I wasn't able to get back to stby state. It appeared my CMD7 with a RCA of 0x0000 was timing out. I'm not sure what I'm doing wrong.

Thanks for listening ... Buzz

Reply to
Buzz McCool

On 4/26/2022 2:15 PM, Buzz McCool wrote: > Would you have any thoughts on implementing a eMMC BCH host driver? >

Pondering this for a while, if the ECC field is just an format announcement, and my eMMC device is soldered to my board, there's really no reason for me to need to set the ECC field as there's only one host accessing the eMMC device. The host should know how it is storing data on the eMMC device soldered to it.

Note that my research indicated though SD Cards are very similar to eMMC, SD cards do not have an ECC field.


Reply to
Buzz McCool

I ended up implementing a Golay encoder/decoder (not BCH), and per the above, didn't bother setting the ECC field from the default.

I asked a lot of forums for help, but only got a response here. Thanks to Dave and all of you who help answer questions here at sci.electronics.design. You are a tremendous resource!


Reply to
Buzz McCool

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.