how psoc6 SRAM simulate eeprom?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
David_Zhang
Level 5
Level 5
Distributor - Arrow(GC)
First like received 50 sign-ins 25 sign-ins

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?

0 Likes
1 Solution
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

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.

backup_domain.PNG

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

Thanks

Ganesh

View solution in original post

0 Likes
2 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

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.

backup_domain.PNG

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

Thanks

Ganesh

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

DaZh,

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.

Len

Len
"Engineering is an Art. The Art of Compromise."