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

Original question:

ECC Malfunction Test Mode 4

TMS570LS1224: FEE - ECC and CRC metadata

Varban Metodiev
Intellectual 690 points
Part Number: TMS570LS1224


Tool/software:

Hi,

Inside the FEE configuration header file (ti_fee_cfg.h) there are definitions for enabling error detection/correction and checksum calculation.

#define TI_FEE_DEV_ERROR_DETECT                 STD_ON

#define TI_FEE_FLASH_ERROR_CORRECTION_ENABLE    STD_ON

#define TI_FEE_FLASH_CHECKSUM_ENABLE            STD_ON

Where does the FEE driver store the ECC and CRC data and how does it work with it?

Is it fully transparent from the API, or there are dedicated byte offsets for that metadata that need to be taken into consideration (and treated as reserved bytes)?

  • 0
    TI__Guru 71411 points

    Hi Varban,

    The ECC will be stored in below highlighted section:

    This ECC is not created in FEE driver, it is the ECC supported by TMS570LS12x controller itself and it will be stored in above highlighted section. However, it would give us ESM errors if any data got corrupted in the EEPROM bank or EEPROM bank ECC sections.

    And checksum will be stored along with data in the block header like highlighted in below image:

    Again, i won't recommend you enable this checksum because this is built using fletcher's checksum algorithm and it have some limitations. Please refer below thread.

    (+) TMS5701224: FEE writing action failed when the corresponding FEE contents before writing is combination of 0x00 & 0xFF and wanted writing data is also combination of 0x00 & 0xFF - Arm-based microcontrollers - INTERNAL forum - Arm-based microcontrollers - INTERNAL - TI E2E support forums

    However, you can use ECC verification for entire EEPROM memory so it may not require to enable checksum.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Intellectual 690 points

    Hi Jagadish,

    Let's consider an example scenario: the user stores certain amount of data in the eEEPROM, in multiple blocks, and after some time, 3 bits from block N become corrupted.

    What is still not clear to me is:
    1) When will the ECC controller detect the corrupted bits and try to repair the data in block N - it is routinely checked, or only upon some trigger to the controller (like read command)?

    2) In case the ECC controller was not able to repair the data, you stated that the ESM will generate an error, but will it specify somewhere (maybe in a status register) which block exactly is the one that has the corrupted data?

    Thanks,

    Varban

  • 0 in reply to Varban Metodiev
    TI__Guru 71411 points

    Hi Varban,

    Varban Metodiev said:
    1) When will the ECC controller detect the corrupted bits and try to repair the data in block N - it is routinely checked, or only upon some trigger to the controller (like read command)?

    In two conditions

    1. The first one is obviously when you read the corresponding location, i mean whenever we read the corresponding corrupted location then ECC verifiacation will fail and we will get uncorrectable ECC error.

    2. Along with first case, the CPU will also do the speculative fetches to the different locations in the ATCM memory (flash or RAM). Whenever this speculative fetch happens in the corrupted memory location then it will again immediately create either correctable or uncorrectable ECC ESM error flags based on the type of error.

    Varban Metodiev said:
    2) In case the ECC controller was not able to repair the data, you stated that the ESM will generate an error, but will it specify somewhere (maybe in a status register) which block exactly is the one that has the corrupted data?

    Yes, it will provide.

    The below highlighted registers will provide the corresponding address of the error.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Intellectual 690 points

    Hi Jagadish,

    Thank you for your informative response. One last thing:

    In case of correctable error upon read operation - will the flash controller return the corrected data?

    Or some additional actions are required by the programmer to query the ECC logic to get it corrected?

    Thanks!

  • +1 in reply to Varban Metodiev
    TI__Guru 71411 points

    Hi Varban,

    Varban Metodiev said:

    In case of correctable error upon read operation - will the flash controller return the corrected data?

    Or some additional actions are required by the programmer to query the ECC logic to get it corrected?

    No additional actions required, except make sure to enable the ECC.

    Enabling ECC for Main Flash (Bank0 and Bank1):

    Setting bit 25 of ARM ACTLR register (Auxiliary Control Register) is to enable the SECDED logic in CPU which is used for main program flash (bank0, and bank1).

    Enabling ECC for EEPROM:

    The ECC protection logic for EEPROM and OTP is implemented in flash wrapper only

    The ECC protection for accesses to the EEPROM emulation flash bank and OTP flash banks can be enabled by writing 0xA to the EDACEN field of the flash module’s Error Correction Control Register 1 (FEDACCTRL1).

    For more details refer below thread once:

    (26) TMS570LS3137: Enabling ECC in Flash wrapper vs in the CPU - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    --
    Thanks & regards,
    Jagadish.