MSP430F2252 Expected Value of Uninitialized RAM

RAM is volatile -- meaning its contents evaporite when there is no power.

CPU and peripheral registers are also volatile. Some of them are cleared or preset at Reset. A few flag bits even provide information about what actually caused the Reset.

Flash Memory are not volatile. They retain their contents for many years with or without power.

When you say "...contents evaporate", does that specifically mean that the contents of all RAM becomes zero with certainty?

A1:  One way is to use a magic key value like this:

   __no_init long magicKey;

And then check it for the correct value after reset.  If it is not the correct value, then your other __no_init values are invalid.  Then reinitialize the magic key.  Like this:

   magicKey = 0xAC3518F0;

A2: The only guarantee is if your supply voltage stays above the RAM retention voltage listed in the data sheet.  Then your RAM is guaranteed still valid.

Jeff

sfloydtn said:

When you say "...contents evaporate", does that specifically mean that the contents of all RAM becomes zero with certainty?

No. They become pseudo-random or quasi-random. Actually, I do not know the answer. But I know that they are not all 1s nor all 0s.

Sorry. My previous responses are all about what happens when the power is turned off.

If the power stayed on, RAM contents will not change due to Reset. Only the CPU or DMA can change RAM contents.

sfloydtn said:

I want to be able to "send myself a message" across powered resets, e.g., to see what was going-on when a reset occurred. 

After powe-on, RAM holds more or less random values. SRAM (as opposed to DRAM)  is more or less an R/S flipflop for each bit. Which has a random, sometimes not even stable state when powered-up. Both states (flip and flop) are equally possible on startup since the circuit is a symmetrical connection of two gates.

So I too suggest using two variables, one holding a magic value, which is unlikely on startup. SRAM startup contents tend to have pattern. Because of the arrangements of the cells in rows and columns, adjacent cells tend to have the same init value due to same physical situation (die position etc.). So a 32 bit magic value that has a non-evenly distributed bit patten is less likely to happen 'accidentally'.

If the variable with the magic key contains something else, this is a cold boot and you have to write the magic value to it and initialize the other uninitialized variables. However, a short power-off may keep the magic value intact while the other values may 'fade' faster.

On some MSPs, there are different ways to detect the cause of a reset. The 5x family has a reset interrupt vector that holds the cause of the last few resets. each read of this register will return a reset cause, sorted by priority, not time. And a power-up of course clears this register and reveals only a power-up reset.
Older MSPs have IFG bits that are only cleared on power-up, so you may see an OFIFG or WDTIFG bit still set for an oscillator fault or watchdog reset etc. (well, the OFIFG is a pseudo reset, since I have an NMI that is triggered on oscilaltor fault and this one triggeres a WDT password violation reset.)

sfloydtn said:

Q1: Is there a better way to "pass" values across powered resets?

sfloydtn said:

What are my guarantees regarding the value of uninitialized RAM?

Excellent response Jens-Michael. Your effort is greatly appreciated.

I've settled on the "Magic" number approach. When it is valid, I or-in TI-defined reset causes (from IFG1) and application-defined "states at reset" into an info memory location (initialized to 0 when a unit is programmed). This gives us better forensic capabilities to assess what a unit has gone through and what it was doing when reset. This way, a bit will be set for all TI and application defined resets that have occurred since a unit was programmed.

Cheers