eMMC ECC field?...

[Buzz McCool]

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

 

[Dave Platt]

In article <t473ju$hch$1@gioia.aioe.org>,
Buzz McCool <buzz_mccool@yahoo.com> wrote:

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?

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.

 

[Buzz McCool]

On 4/25/2022 2:59 PM, Dave Platt wrote:

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.

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.\"

and

\"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

 

[Dave Platt]

In article <t479c5$grh$1@gioia.aioe.org>,
Buzz McCool <buzz_mccool@yahoo.com> wrote:

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

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.

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.\"

and

\"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%.\"

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.

 

[Buzz McCool]

On 4/26/2022 11:21 AM, Dave Platt wrote:

Here\'s how I understand it. ...

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

 

[Buzz McCool]

On 4/26/2022 11:21 AM, Dave Platt wrote:

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).

On 4/26/2022 2:15 PM, Buzz McCool wrote:

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.

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.

Buzz

 

[Buzz McCool]

On 5/2/2022 10:00 AM, Buzz McCool wrote:

On 4/26/2022 11:21 AM, Dave Platt wrote:
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).

On 4/26/2022 2:15 PM, Buzz McCool wrote:
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.

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.

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!

Buzz