Hello All:

Is there a way to preserve the contents of a section of RAM between resets on the PSoC5?  I have tried several methods without success. 

1.  Using  int KeepMe[11] __attribute__ ((section (".bss")));
Theoretically the .bss section is uninitialized in contrast to .data.  However, all variables are set to 0 on Reset.

2  Modifying the cm3gcc.ld file to start ram at a higher address
MEMORY
{
rom (rx) : ORIGIN = 0, LENGTH = (262144 - 0)
/* ram (rwx) : ORIGIN = 0x20000000 - (65536 / 2), LENGTH = (65536 - 0x4000 - 0x1000) */
ram (rwx) : ORIGIN = 0x20000400 - (65536 / 2), LENGTH = (65536 - 0x4000 - 0x1000)
tkeep (rw) : ORIGIN = 0x20000000, LENGTH = 1024
}

3.  Tried various compiler flags.

All without success - the ram is set to zero on reset!

I would be much obliged if anyone can suggest a way with perhaps a snippet of code or even some pointers.

Thank you!

William

Why do you need that? Not initializing RAM means you have no guaranteed initialization even after a brown-out or power-on-reset, which is a bad thing.

How do you want to distinguish between a (manual) reset, and a power-on event?

If you want not to loose an internal state, why not writing it to the internal EEPROM?

Thank you for your reply.

I have a special application that  requires me to keep some counter state in RAM through resets (push button, watchdog and soft resets.  Not power fails).  Keeping it in eeprom  is too slow and then there is the life of the eeprom to consider.  Checksums on the counter block will tell me if there is a problem or not.

I use this method with other processors with great success.  I love the capabilities of the PSoC but I do need this feature.  I need to know if the processor automatically zeros out RAM on physical reset (not power fail) or is it part of the crt initialization routines.

I cannot find the sources to the crt* routines for me to examine.

Thank you again,

William

With respect to EEPROM, in the scheme of things, eg. chip startup and initialization,

maybe the 32 mS time to store on power loss, a Cap to hold up power, and read time

are not a large burden. Your design criteria governs of course.

The EEPROM lifetime is row related. The million cycles can be extended quite easily

by keeping track of # writes, and moving data when that rows life is exhausted, just

a thought. Same techniques can be applied to FLASH on a block basis.

Regards, Dana.

I still would like to understand why you need to keep this state during reset, but not during power-off. Can't you just ensure no reset occurs? (If you need this triggering capabilty, there are still interrupts which can be used).

Thank you both for your suggestions.

I have to keep counters and state variables (bitmaps of relay states) that accumulate the average of frequencies, voltages etc or maintain the state of relays that must be impervious to Resets.  If there is a glitch, brownout or the like the states and values should remain.  The equipment works in very electrically noisy environment. The reset code differentiates between a cold reset and a powerup reset and works accordingly.  The data in ram (averages and state ) may change in mS, so storing it in NVM is not an option).

I have this code working well on different processors where .bss is different from .data space in their respective compilers.   At this point I need to determine whether the PSoC hardware zeros out RAM or it is handled by the GCC startup code (crt*) for which I do not have sources.  If it is in the code then it will be easy to fix.

I hope this answers the questions as to why I so need this matter resolved. 

All the best,

William

The PSoC architcure TRM say, in part 11.3:

SRAM  data  is  maintained  during  all  low  power  and  sleep modes. At reset, the SRAM contents are not initialized; they power up as unknown values.

So it's the startup code doing this. The System reference guide says (in part 13) that the cy_boot component is handling this, and is clearing all the static and global variables. But unfortunately I cannot find any code doing this. Maybe it#s something done by the linker - then the GCC documentation should have a word about this.

I have two ideas which might help:

• store the values in an integer array (which hopefully won't get initialized during boot)
• or use an external sRAM (like Microchip's 23K256), where you can control the initialization by yourself

I also found out that there is a '.noinit' directive (see http://stackoverflow.com/questions/11180892/force-gcc-to-forgo-zeroing-certain-globals ) - maybe this helps?

Thank you for your valuable research and input. 

The use of external SRAM is a good idea and is my fallback.  I had tried the .noinit way before without success.  the PSoC3 has a flag in the DWR that prevents the RAM from being cleared on RESET.  Alas that is not the case with the PSoC5! 

I have checked out all the linker switches and tried numerous experiments which leads me to believe that it is indeed crt0* code (startup) that zeros out the RAM as the SRG states in Chapter 13.  If we could get the sources we could easily fix the problem.  I am trying to get it from Cypress.

You should be commended for all your efforts in trying to help fellow PSoC users!  So thank you again!  All the best!

William

Using an external FRAM device can be an option but you will increase cost and board space.

If you have external watchdog or RTC chip, you can use some of the unused RAM inside these chips.

You can use the serial SRAM , serial NVRAM, I think microchip has these 8 pin devices. 

Cypress has broad portfolio nvSRAM devices

Serial nvSRAM - http://www.cypress.com/?id=3489

If you main concern is loss of power, brownout, this might assist you.

Attached is a method to compute caps to hold up a supply long enough to

do saves to EEPROM. That way you do not need external components.

Note it targeted PSOC 1, but principles apply to PSOC 3/5.

Just a thought.

Regards, Dana.

My bad.

Yes you are right, Cypress also has the serial RAM, Sooooooooooooooooory :-)