• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 622 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

[TCI6638K2K] DDR3 ECC - error injection

Matija Glavinic Pecotic
Genius 3040 points
Other Parts Discussed in Thread: TCI6638K2K

Hello TI Team,

we would like to test our DDR3 - ECC enabled design by injecting single and double errors. I went over documentation, and unfortunately I havent found means to inject errors.

Could you please help with this? How can we test ECC i.e. inject errors?

We are using our custom board with ECC enabled on DDR3A, and SoC is the one from subject (TCI6638K2K).

Thanks and regards,

Matija

  • 0
    TI__Guru**** 190406 points

    Hi Matija,

    I am sorry, we no longer offer direct support for this device on the E2E forum. You may search the E2E forum for archived posts of previous discussions which may help address your questions. For more info on TCI6638K2K support, please see the FAQ in:

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/809582/faq-tci6638k2k-support-guidance-tci6638k2k-tci6636k2h-tci6630k2l-66ak2l06

      Although I have no experience and knowledge on this particular device and the recommended method to inject ECC errors, I have some general knowledge about ECC. What I can suggest is that you disable ECC first. You should already know the intended test data to be written to the memory with the associated ECC checksum. Manipulate the data to create a one or two bit faults and then write the manipulated data and the original checksum to the memory. Enable ECC and then read back. That should be detected as an ECC error. 

    As recommended on the product folder and in FAQ , please feel free to reach out the 3rd parties listed in them for additional support.

    Regret the inconvenience and lack of guidance on this.

  • 0 in reply to Charles Tsai
    Genius 3040 points

    Thanks for the suggestion, however this idea did not help. Enabling ECC results with CPU hang (I can see it goes to exception). This is most likely due to fact that enabling ECC results with DRAM training being initiated. I tried to work with ranges, as in enable/disable on ranges, but this brings no results, and documentation is not clear on whether one can reconfigure ECCADDRn registers while ECC EN is set, and DRAM in use.

  • 0 in reply to Matija Glavinic Pecotic
    TI__Guru**** 190406 points

    Hi,

      I wish I could help but I don't have the knowledge to answer your question. As mentioned, this device is no longer in ti.com and therefore the support is very limited. I'm not sure why CPU would hang.

      - Will CPU hang if you don't enable ECC with the intentional corrupted data?

      - Will CPU hang if you enable ECC but do not intentionally corrupt the data?

      - Are you intentionally corrupting the data for read or instruction for code fetch? 

     I will suggest you contact the mentioned 3rd party partner in the FAQ for support as my knowledge in this device is very limited. 

  • 0 in reply to Charles Tsai
    Genius 3040 points

    Let me explain that scenario a bit better. ECC is enabled in our bootloader (uboot) together with DRAM initialization. I need to test this from Linux. I tried your approach with following scenario:

     - ECC is enabled in uboot

     - Boot Linux

     - Do write/read to one memory location

     - Disable ECC

     - Do write to the same memory location, data same as before with difference in 1 or 2 bits (depending on what I tried to provoke)

     - Enable ECC - cpu goes for exception (I see Linux starts to print exception trace on the console, but only few characters), and then cpu hangs

    I believe cpu hangs due to fact that datasheet says that DRAM training is initiated on ECC enablement, invalidating DRAM, which is being used at the moment.

    Same scenario happens as well without step in which I write to the memory location, however, since DRAM is anyway used, there are writes happening in any case at this time. Same scenario happens as well when ECC interrupts are kept disabled.

    I believe problem with this approach is trigger of the training. From spruhn7c:

    31 ECC_EN ECC enable. Enabling ECC will cause the DDR3 controller to start the SDRAM initialization
    sequence.
    • 0 = Disable ECC
    • 1 = Enable ECC

  • 0 in reply to Matija Glavinic Pecotic
    TI__Guru**** 190406 points

    Hi,

      Sorry, if my earlier suggestion did not work then I have nothing to offer. Please contact the 3rd party partners in FAQ for support. Sorry for the inconvenience and lack of guidance here.