This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L952: Unclear behavior of ECC

Part Number: RM48L952

QJ Wang, 

sorry but your answer to 

https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/807881#pi320995=2

it is not an answer at all.

The recent habit of tagging TI's answers as "TI thinks resolved" is really disappointing. The problem is not really resolved, we have shown you a strange behavior and it is clear that you don't care. I'm not saying it couldn't be our mistake but in absence of exhaustive documentation and examples we needed your help. 

Valerio

  • Hello Valerio,

    -   If I call the checkB0RAMECC()_mod function periodically, tcram1ErrStat is set just the first time I call the function. From the second time that I call the function, the flag is not set anymore as if the error is not corrected.

    QJ>

    It is expected.

    CPU will read from the cache instead of reading from the SRAM if the address is same. This cache is a special buffer designed for ECC, and it is not user visible.

    The Cortex-R4 processor attempts to correct 1-bit errors in the SRAM by writing the corrected data back to the SRAM and retrying the access. If a 1-bit error is due to a hard fault, then doing this will not change the data read from the SRAM, and when the access is retried, the same error will be detected again and the processor will livelock, forever detecting the error and retrying and not making any progress.

    The purpose of the hard error cache is to prevent CPU from reading the SRAM which has permanent single bit error. Let's say there is a defect in one of the memory cells. If you read from it the CPU will detect it as a single bit ECC error. What the CPU will try to do is to save the corrected data to the hard error cache and also write back the corrected to the SRAM and then retry. Next time if the CPU reads from the same error address then it simply read from the cache instead of reading from the SRAM since there is a match in the address.

    You can do like this:
    1. address 1: corrupt its ECC, read the data to get ESM error
    2. address 2: corrupt its ECC, read the data to get ESM error
    3. address 1 again: corrupt its ECC, read the data to get ESM error

  • Hello Wang,

    but you just copy and paste the answer you gave in the post https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/807881 ?!?!?!?!?!?!

    I needed clear answers to questions in post https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/807881/3054661#3054661, the answer you gave sorry but are incomplete to me.

    Valerio

  • # If I call the checkB0RAMECC()_mod function periodically, tcram1ErrStat is set just the first time I call the function. From the second time that I call the function, the flag is not set anymore as if the error is not corrected.

    As I said, CPU reads from the cache instead of the SRAM if the address is same.

    Please let us know which part of my post (nov 3rd) is unclear.

  • Do you mean those questions?

    1. The 8 bytes for a single ECC location are not equal within the same 64 bit (it should according to your documentation)

    2. ECC doesn't change anymore after the first write to RAM

    3. A data abort is raised if read is performed on a second location and then back on the first location