1 Reply Latest reply on Aug 7, 2019 11:01 PM by GeonaP_26

    What are potential causes of Em_EEPROM data corruption?

    GrCa_1363456

      The Em_EEPROM component documentation eludes to recovering from “damaged EEPROM data” on page 23 of Version 2.20, Rev *A under Redundant Copy.

      Here's a few specific questions relative to potential damage and protection:

      1 Does “damaged EEPROM data” cover the case where a block of memory, containing an Em-EEPROM, becomes zero'd out? 

      2 What might be the cause of “damaged EEPROM data”? 

      3 What drove the decision to implement a Redundant EEPROM option in the PSOC? 

      4 Are there any specific design recommendations that will increase reliability of Em_EEPROM data?

      5 What are the advantages of using EEPROM vs Em_EEPROM? 

       

      Reference - Cypress Emulated EEPROM component @ https://www.cypress.com/documentation/component-datasheets/emulated-eeprom

        • 1. Re: What are potential causes of Em_EEPROM data corruption?
          GeonaP_26

          1. The Emulated_EEPROM (Em_EEPROM) read operation looks valid checksum either among active or redundant copies. If the entire Em_EEPROM data content is zeroed out, error status will be returned without data.

           

          2. There are a number of causes such as reset and power failure during Em_EEPROM operations. Please refer to following lines from Em_EEPROM datasheet.

          The user firmware should not enter Hibernate mode until write is completed. The write operation is allowed in Sleep and Deep-Sleep modes. During the flash operation, the device should not be reset, including the XRES pin, a software reset, and watchdog reset sources. Also, low-voltage detect circuits should be configured to generate an interrupt instead of a reset. Otherwise, portions of flash may undergo unexpected changes.

          The same applies for Em_EEPROM erase operation as well. If Em_EEPROM operations are hindered, data content might get damaged.  

           

          3. The reason for change is to improve and match the industry norms for emulated EEPROMs such as wear leveling and redundant data copy features.

            

          4. For data integrity and higher number of read/write cycles,

            • Enable redundant copies depending on the flash resource availability.
            • Set wear level factor to increase the read/write cycles. Higher the wear level factor set, higher number of read/write cycles can be performed in the Em_EEPROM. This will also increase the flash usage. So, set the wear level factor judiciously.
            • Perform an Em_EEPROM_Read after initializing the Em_EEPROM device. This will perform checksum validation and retain valid data content if any (in case of damage) before performing writes.
            • It is also recommended to perform read after a write operation for the same reason.

           

          5. EEPROM is byte addressable and of lesser size i.e., 2kb. Whereas, emulated_EEPROM component tries to emulate EEPROM data storage in flash. Hence, it is row addressable (refer to device datasheet for flash row size) and supports higher size depending on the flash resource limitations in the project. Also, note that 2kb EEPROM is in addition to the flash address space.