• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 1428 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problem with the mechanism of ECC Data Correction Diagnostic Mode 7: DIAG_MODE = 7

cc liu
Expert 1150 points
Other Parts Discussed in Thread: HALCOGEN

Hi All

I am looking into the ECC Data Correction Diagnostic Mode 7: DIAG_MODE = 7.

In the document says:The value in the DATA_INV_PAR register will be XORed with the current ECC to give a bad
ECC value to the CPU.

how that happened?

I mean if the 64bits data is all zero. and the correct ecc is 0x0c , in the code generated by halcogen, the  DATA_INV_PAR  is 0x01, after XORed operation, the returned ecc is 0x0D, how the CPU judge data value: 0x00  and ecc code 0x0D  has an one bit error?

and if I read from other location of memory, will the test still work? if I read from 0x20000030U  instead of 0x20000000U.

and why this single bit error is an "a zero was read as a one"  not  "a one was read as a zero"？

and  can I use esm status to see if the error can be detected?

Any reply will be appreciated

Best Regards

Leo

  • 0
    TI__Guru**** 159385 points

    Hi Leo,

      Please refer to your device TRM and in the F021 Flash Module Controller (FMC) chapter section you will find the table below. Since you are entering 0x01 into the DATA_INV_PAR then look for the intersection between row 0x and column x1. I have highlighted 

  • 0 in reply to Charles Tsai
    TI__Guru**** 159385 points

    Sorry, I haven't finished my typing and hit the reply by mistake.

    Please refer to your device TRM and in the F021 Flash Module Controller (FMC) chapter section you will find the table below. Since you are entering 0x01 into the DATA_INV_PAR then look for the intersection between row 0x and column x1. I have highlighted the intersection and it is E00. By doing a XOR between the ECC=0xC with 0x1 in the test register, you are intentionally flipping the ECC0 bit. This will cause the CPU to think that there is a bad bit at the ECC0 bit. Let's give another example, let's say you want to make the CPU think that bit60 in your data is bad. How do you do it? Look at the table where I have hightlighted in yellow for D60, the corresponding row and column is 0x6B. If you enter 0x6B into the test register while in diagnostic mode 7 then the CPU will think that bit60 is bad and try to correct it. 

  • 0 in reply to Charles Tsai
    Expert 1150 points
    Dear Charles
    Thank you very much for your elegant explanation . I try this and I observe the change of data though memory browser.
    But I saw that all the data in memory has one bit flipped at bit60, and I observe that the data from 0x00 has changed simultaneously.
    will it has side effect on my software as all the data has been changed intentionally. I had assumed that only one 64bits data at specified location will be flipped. Is that the reason for why we dont flip the memory data ,we flipped the ecc data?
    and for the test for double bit ecc check, it read from 0x20000010U, we know that ecc is 64bits data with 8 bits ecc code, so must we read from the address of 0x00 0x08 0x10, the multiple of 0x8h, we cant read from 0x04,am I right?
    Thank you for you reply
    Best regards
    Leo
  • 0 in reply to cc liu
    TI__Guru**** 159385 points

    HI Leo,

     Are you using the mirrored image to test the data? For example, if you have a data that you want to intentionally flip a bit and this data is stored at address location 0x00010000. You don't just write 0x6B into the test register and read from the location at 0x00010000 to flip bit60. The reason is that you are executing code at the same time from the flash. Every read access from the flash will get the their bit60 flipped. What you need is to read from the mirrored address of 0x00010000 which is 0x20010000. This will prevent your normally read (i.e. reading from 0x0, 0x4, 0x8.....) from getting their bit60 flipped. Please refer to the userguide. I have also copied the below excerpt from the userguide. The recommendation is to test one location and then turn off this test mode. 

    The sequence to do this test would be:

    1. Make sure the true DMA module is off.

    2. Put 0101b into PAR_OVR_KEY and 101b into DAT_INV_PAR fields (00005Axxh) of the FPAR_OVR register (0x7C).

    3. Put the desired value in DAT_INV_PAR field of FPAR_OVR register.

    4. Put 7 in DIAG_MODE, and 5 in DIAG_EN_KEY of FDIAGCTRL (0x6C).

    5. Do a slave access of the desired address. Note this is the mirrored address location

    6. Put 0 in DIAG_MODE or A in one of the key fields to turn off this test.

    7. Check error registers for ECC errors. (0x14, 0x1C, 0x20).

    8. Repeat as necessary to test out the ECC.

    9. Put 0 in DIAG_MODE and A in both of the key fields to completely disable this test at the end of the test.

    10. Write 5400h to FPAR_OVR(0x7C) to clear DAT_INV_PAR and put 2 into PAR_OVR_KEY.

  • 0 in reply to Charles Tsai
    Expert 1150 points
    Dear Charles
    Thank you for your explanation, your description conformed to what I observed.
    When I put the 0x6B into the register and trigger the test. All the data in the mirrored flash(starts @ 0x20000000) has been changed, for every 64bits data, but for main flash(0x00), no change to them. and after I read at location 0x20000000,all the data has been corrected back.
    so I got another two question：
    Does it matter that I read at other address? I had thought the CPU will only correct the 64bits data at which I read,but i was wrong.
    when I change 0x20000000 to 0x20000030, I found that all the wrong data have been corrected back.
    thus, my speculation is whereever I read, the CPU ECC will correct all the data. But if this is true, everytime you execute one code, the CPU ECC do the correction once, will be too much burden to the CPU?
    Looking forward to your answer. Many thanks.
    Leo
  • 0 in reply to cc liu
    TI__Guru**** 159385 points
    Hi Leo,
    The question is is whether you want to test 0x20000030 or not? If you only want to test one location then after you verify that location you should disable the test. In the steps that I listed, the step 8 says to repeat as necessary to test out the ECC. If you try to test several addresses from 0x20000000 to 0x20000030 then every 64-bit words within this address range will be injected with a single bit fault. If you just want to test one location then you should skip step 8 and disable the test by taking step 9 and 10.
  • 0 in reply to Charles Tsai
    TI__Guru**** 159385 points
    Hi Leo,
    If your question answered is answered can you please click the 'Verify Answer' button to close the thread? Thanks.
  • 0 in reply to Charles Tsai
    Expert 1150 points
    Dear Charles
    Thank you for your answer, i need some time for digestion before being sure I have no further question.
    It is verified now. tks
    Leo
  • 0 in reply to cc liu
    TI__Guru**** 159385 points
    Hi Leo,
    If you have new question you can always open a new post.