KE1 ECC RAM Single Bit Corrrection

[sean_dvorscak]

Have a few questions regarding ECC.

I am currently using the MCM_LMFAR to determine where the ECC triggered a fault and then using that address to read then write back to correct it.

Questions:

1. Does the ECC have the ability to autocorrect bits? Or do I really need to perform this read/write to address to correct?

2. If there is not autocorrect, will I need to compensate for byte alignment when performing my read/write correction mechanism? Currently I am performing a 4-byte read/write at the address denoted by the MCM_LMFAR. I feel like this is dangerous as I am not sure the MCM_LMFAR will always show a 4-byte aligned address.

[Celeste_Liu]

Hello @sean_dvorscak ,

Thank you for your post.
Could you please let me know which specific device in the KE1 family you are using?
This will help me locate the relevant documentation more accurately or perform validation using the same device.

BR

Celeste

[sean_dvorscak]

It's a KE18F512VLH16.

Thanks for your help.

[Celeste_Liu · Accepted solution]

Hello @sean_dvorscak ,

Thanks for your reply.

So for your questions:

1. Does the ECC have the ability to autocorrect bits? Or do I really need to perform this read/write to address to correct?

->> Yes, ECC does support hardware correction for single-bit errors. So you should not need a software read/write sequence to obtain corrected data. 

2. If there is not autocorrect, will I need to compensate for byte alignment when performing my read/write correction mechanism? Currently I am performing a 4-byte read/write at the address denoted by the MCM_LMFAR. I feel like this is dangerous as I am not sure the MCM_LMFAR will always show a 4-byte aligned address.

->> If implementing an optional scrub, please align the access according to the actual access size or scrub granularity, not blindly to the raw MCM_LMFAR value. Also don't use a fixed 4-byte access unless you first align the address appropriately and confirm the access size is valid.

In fact, For multi-bit / non-correctable ECC events , do not assume a read/write can repair the data, you should treat it as data corruption and recover from a known-good source or reinitialize the affected memory as appropriate.

Hope it helps.

BR

Celeste

---------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you!
---------------------------------------------------------------------------------------------------------------------

[sean_dvorscak]

Have more follow up questions.

Does the hardware correct the data within the Memory Cell, or only on the Read Out Data?

Example from AN5335, is the Read-out Data being corrected from 0->1? That would mean we need to write back the corrected value to RAM to actually clear it.

sean_dvorscak_0-1785962043300.png

We are concerned if the data in the RAM memory cell is not corrected, a single bit error could degrade to a double bit error.

[Celeste_Liu]

Hello @sean_dvorscak ,

I noticed that this thread has already been closed. To help us better track and follow up on this issue, could you please create a new post? Thank you for your cooperation.

BR

Celeste

[sean_dvorscak]

One more question actually.

The automatic HW ECC correction functionality is enabled by default? I don't really see any bits in the MCM registers that would suggest it's a feature that can be disabled/enabled.

[Celeste_Liu]

Yes, ECC checking/generation is enabled by default after reset.

[sean_dvorscak]

Thanks for the confirmation and info.

And yes, I am handling uncorrectable bit errors differently.