LC4357 Flash ECC

Still not clear. SECDED should correct only one mistake and only informing about two or more.
By reading flash I see that something change (try to correct?) regions with 2 or more mistakes.
But why I can't understand.

On Monday I will try that method and will return to the topic.

Thank you.

Dmitry,

I think you're seeing the effect of multiple rounds of ECC correction.   If you use the DAP to view the erased flash instead of the CPU you see only the correction performed by the flash wrapper - which looks to be either 1 bit or 0 bits flipped..   That's what the flash wrapper is supposed to do - only provide the correction for single bit errors ..

[EDIT:  I used the same filename and uploaded the CPU case twice.. fixing that now..  Here is the DAP view again:]

The very same flash viewed through the CPU has more corrections:

I'm not sure exactly what the CPU does to the data when it's > 1 bit error - would need to look that up.  But I suspect that some of what the flash wrapper is outputting are multi-bit errors that alias to single bit and then when these go to the CPU's ECC they get corrected again.

More time spent analyzing and we could probably explain precisely - but I think there's no need to be 'alarmed' that the logic is behaving wrong.  Just probably not obvious that more than one ECC step is applied.    There's at least one ECC inside the flash wrapper which takes the address lines into account in addition to data lines.  Then there's another ECC at the CPU to protect errors introduced in the interconnect.   There may be more even - but you just need to make sure that the FLASH itself is programmed with correct ECC to match it's data.   If this happens then the rest of the corrections won't get applied unless there is a real error (hard or soft)..   These errors where the flash and ECC are all erased are very artificial.

Hello Anthony,

thank you for the answer.
I just want to clarify one additiional point.

I checked ECC region for bank1 (blank bank) and all values there 0xFF.
Additionaly I calculated ECC values for complete address space of bank 1.
Some values should leads to "E0x - Single bit ECC error, correctable" in accordance with Syndrome Table.

As example for flash address 0x3DADB0 with value 0xFF for 8 bytes, ECC should be equal to 0x7F.
0xFF XOR 0x7F = 0x80. By syndrome table it is E07. But E07 is not corrected, it is still 0xFF.

Why flash is corrected automaticaly but ECC region not? Is it desider?

P.S. I asked because I need to find more or less stable algoritgm to check flash for blank.
API function is not work correctly, direct flash read also.
So I want to try check it by corresponding ECC now.

Dmitry,

I just did a spot check and I get bit 7 of the ECC as '1' not '0' (0 leading bit of 0x7F...)

Manually did this.   The ECC value for bit 7 is the XOR of the address >> 3 with 0x1FC007F.

When I do this I get 0x3DADB0 >> 3 = 0x7B5B6

0x1FC007F

0x007B5B6

xor

0x1FBB5C9

This value has 1 + 4 + 3 + 3 + 2 + 2 + 2 bits set to 1, or 17 bits.  So the XOR result would be 1

The data if it's all 0xFFFFFFFF 0xFFFFFFFF when XOR'd with 00FFFF00_FF0000FF would produce an XOR of '0' because it's either 0 xor F -> F  or F xor F -> 0 both are even, for each nibble.

So at the end, I think bit 7 is '1'.

I missed the >>3 in the address though initially.   Are you taking that into account if you use 0x1FC007F?

-Anthony

Hello Anthony,

sorry for the delayed answer.

Here is my opinion and understanding of the manual.

1. No,I don't forget 0x1FC0007F & 0x7B5B6 = 0b0011 0110. Count of enabled bits is even, so XOR of them gives 0.

2. I can't understand why do you use XOR to caclulate ECC. For the first, we need to mask necessary bits and I preferred to use AND for it. 

3. I checked ECC calculation by F021 API, here is the screenshot:

So, taking into account all of it and syndrome table I still can't understand why ECC is not corrected and shown as 0xFF in memory viewer.

Hope for your help with this question and hanks a lot in advance.

Dmitry.