Author Topic: SRAM state after SW reset?  (Read 9693 times)

Offline syakovlev

  • Newbie
  • *
  • Posts: 20
    • View Profile
SRAM state after SW reset?
« on: July 10, 2009, 08:10:31 PM »
CFM52235 RM says that state of SRAM is undefined after HW reset .
What about SW reset?
Looks like there are two possibilities: to be udefined or to be unchanged.
Link to document ( or firm statement:) ) will be appreciated.

Thanks,
S.Y.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: SRAM state after SW reset?
« Reply #1 on: July 10, 2009, 09:42:42 PM »
Hi

A warm reset (push button or commanded) causes the processor and peripherals to be reset but doesn't change RAM content.
This allows, for example, a pattern to be placed into SRAM before a soft reset, which can be read afterwards for interpretation.

However do note that system variables will (usually) be initialised again immediately during the start-up code. Also the free, unallocated area below the initial stack pointer will normally be initialised with a pattern (for stack usage identification).

Regards

Mark

Offline syakovlev

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: SRAM state after SW reset?
« Reply #2 on: July 11, 2009, 01:58:37 AM »
Mark wrote:
>"This allows, for example, a pattern to be placed into SRAM before a soft reset, which can be read afterwards for interpretation."

Exactly! This is what I'm trying to do.
To prevent loggin data from being overwritten during following soft restart, special .log section of ram has been created.
It's allocated in between .data and .bss sections.
Now I know that I'm on right track.

Thanks,
Sergei.


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: SRAM state after SW reset?
« Reply #3 on: July 11, 2009, 08:39:31 AM »
Hi Sergei

A non-initialised variable area is a possibility.
Another method is to put such variables on the stack of extern int main(void) - although these are more difficult to access globally.
An example is the variable usRandomSeed, which is used as a 'random' SRAM value after power up. On subsequent warm resets it retains its value and so is used to continuously prime the random number generator.

Regards

Mark