2 Replies Latest reply on Mar 22, 2020 6:50 AM by LePo_1062026

    how  psoc6  SRAM simulate eeprom?


      hi  CYPRSS:

           how to use psoc 6 sram simulate eeprom to store the RTC data when the watch dog reset , the RTC date can store for the same?

        • 1. Re: how  psoc6  SRAM simulate eeprom?



          In PSoC 6 RTC is a separate IP/block which has registers to store the RTC data. The RTC information retains even when the device resets. This is possible because RTC works on separate power domain called VBACKUP.




          So there is no need to store the RTC data separately in SRAM. Please go through code examples related to RTC in PSOC Creator.




          • 2. Re: how  psoc6  SRAM simulate eeprom?



            Did Ganesh answer your question?


            In general, PSoC SRAM cannot emulate EEPROM.  This is because if VDD drops below 1.7V, the contents of SRAM is not guaranteed.  Unlike EEPROM where the contents can survive a VDD = 0V for indefinite periods of time.


            This also applies to internal PSoC registers powered off of VBACKUP.  If VBACKUP drop below 1.7V, the register contents are assumed to be lost or scrambled.


            However, PSoC SRAM can survive (retain its data) past non-VDD caused reset such as a watchdog or software reset.  A note of caution:  Cypress-supplied startup code run immediately after the reset (before main() is reached) will initialize SRAM to 0s.  By supplyin your own startup code, you can prevent this for all or just some of SRAM.  In this case, the SRAM contents can survive most resets except for VDD dropping below 1.7V.


            If you want to have some SRAM survive a non-VDD caused reset, I recommend that the SRAM section of code should be:

            • collected together in a small region of SRAM (For now let's call it CRAM).  There are compiler pragmas available to do this. This minimizes reset survivable CRAM scatter.
            • Modify the Cypress startup code to prevent CRAM initialization.
            • Add a CRC (preferred) or Checksum in this area of CRAM.  (The "C" stands for CRC or Checksumed SRAM).  A 32bit CRC/Checksum is preferred.  16bit or 8bit is less so.
              • Every time you modify ANY content of this CRAM section, the CRC/Checksum is updated.
              • When a reset occurs, validate that the CRAM to be correct.  If not correct, set a global flag for the Application to use to not trust the CRAM.


            After all is said, EEPROM (or FLASH) is potentially more reliable but even if you use true non-volatile memory I still recommend the CRC/Checksum to detect corruption.  The PSoC 6 has middleware library that allows you to save to non-volatile and a CRC validation is selectable.



            1 of 1 people found this helpful