• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 1504 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.

TMS570LS20216 Flash ECC Test

Jeremy Henderson
Intellectual 740 points
Other Parts Discussed in Thread: TMS570LS20216, HALCOGEN, TMS570LS3137, NOWECC

1. I am using the TMS570LS3137 and TMS570LS20216. I am trying to write functions to test the Flash ECC functionality of each chip. For the 3137 HalCoGen provides the fmcBus2Check and checkFlashECC functions to do this. Are there equivalent functions for the 20216? HalCoGen does not generate any selftest functions for the 20216.

 

2. Is there a way to automatically generate the ECC values for the 20216 while loading? Similar to the 'Auto Generate ECC' on the 3137. I would prefer to not have to manually execute nowecc, is there a way to incorporate nowecc into Code Composer Studio's build/load process?

  • 0
    Intellectual 740 points

    Bumping this post. I am still looking for an answer to this. Is there any way to test the 20216 flash ECC detection during run time, without having to reload the ECC area of flash?

  • 0 in reply to Jeremy Henderson
    TI__Guru 68830 points

    Jeremy,

    Thanks for bringing this forward in the list, looks like we missed your question last week.   Apologize for that.

    The best that I could find for Question 1: is this application report:  http://www.ti.com/litv/pdf/spna126   Section 2.5 has some information on ECC diagnostics.  Not nearly as comprehensive as the HalCoGen code that comes with the 3137, but something.

    For Question 2: Compiler version 5.1 has added support for ECC. See section 8.5.8 of http://www.ti.com/lit/ug/spnu118l/spnu118l.pdf for information on inserting the ECC data into the .out file.

    Also, see 8.4.11 of the same document for information on how to insert ecc errors in your image for test purposes.

     

  • 0 in reply to Anthony F. Seely
    TI__Mastermind 49120 points

    Jeremy,

    The OTP locations on the LS20216 MCU is also mapped to the tightly-coupled memory (TCM) space of the Cortex-R4F CPU. That means that the CPU is expecting to fetch an 8-bit ECC value along with 64-bit data on a read from this space when ECC checking is enabled. This allows you to check the CPU ECC in the following way.

    The TI OTP for bank 0 starts from address 0x00604000. The 64 bits starting from address 0x00604200 are 0x123456789ABCDEF1 and the corresponding ECC is calculated for a 64-bit data of 0x123456789ABCDEF0.

    Thus reading from 0x00604200 will result in a single-bit ECC error.

    Similarly, the 64 bits starting from address 0x00604208 are 0x123456789ABCDEF3 and the corresponding ECC is calculated for a 64-bit data of 0x123456789ABCDEF0.

    Thus reading from 0x00604208 will result in a double-bit ECC error.

    You can read from these two locations to verify that the ECC logic inside the CPU as well as the signaling mechanism to ESM and the nERROR pin action is working correctly.

    I will see how to best get this information into the documentation.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 740 points

    Hi Sunil,

    I was able to get the single-bit error by reading 0x00604200 like you said. I had to set FEDACCTRL1 to 0x000A020D to ensure that ECC errors from OTP were not blocked. The double-bit error also worked. My only other question is how can I indicate to the data abort routine that the double-bit error was intentional? In the 3137 the data abort routine looks to see if diagnostic bits are set.

    Is it typical to block ECC errors from OTP in normal running conditions? I was thinking I could set EDACEN to 0xD in my test function then check EDACEN in the data abort routine. If EDACEN is 0xD in the data abort, then it is intentional, the idea being that in normal running conditions EDACEN is 0xA.

  • 0 in reply to Jeremy Henderson
    TI__Mastermind 49120 points

    Hi Jeremy,

    You can read the address at which the ECC error was detected. There are registers inside the flash interface module for this. The FCOR_ERR_ADD register at 0xFFF87014 shows the 64-bit aligned address for the 1-bit error, and the FUNC_ERR_ADD register at 0xFFF87020 shows the 64-bit aligned address for the 2-bit error.

    You can also read the address that has the ECC error from CPU fault address registers. Please refer to the ARM Cortex-R4F TRM for information on these registers.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 740 points

    Thanks Sunil, that works.

    I have noticed that I cannot get the single bit error to be detected back to back. For example if I run my single bit flash ECC test function, the first time it will detect the single bit error, I clear all of the errors in the ESM and Flash registers. Then if I run it again, it will not detect the single bit error. However, if I create a single bit error in RAM then run my flash test again, the single bit error will be detected. It's like it needs a different single bit ECC error to occur before it can detect the first one again. Is this expected?

  • 0 in reply to Jeremy Henderson
    TI__Mastermind 49120 points

    Jeremy,

    Yes, this is expected. The Cortex-R4F CPU has a built-in single-entry ECC error cache, which it uses to keep track of a TCM address for which it last detected a single-bit or double-bit ECC error.

    This cache consists of one 64-bit entry shared between the three TCM ports (ATCM for flash, B0TCM and B1TCM for RAM). For a single-bit error, this cache also contains the corrected 64-bit value. When an access is retried to a location where an ECC error is detected, the data is returned from this cache as opposed to the actual TCM. This is why you do not see the single-bit error again.

    The ARM CPU TRM contains a fleeting mention of this TCM Hard Error Cache but provides no further details on its operation. We have already submitted several requests for ARM to provide better documentation of this feature.

    Regards, Sunil