SRAM Initialization

Would it not be safer to accomplish your goal by "reserving" a "safe area" w/in the MCU's flash?  Gone then are both your reset & power-up worries.  (not to mention the requirement for battery or other "reserve power" for SRAM.)

There are certain restrictions mandated - good review of your data manual should unlock...

Robert,

SRAM is an inherently volatile type of memory. As cb1 suggests, if you want to preserve your data during power off and reset, you must store it in flash.

I first thought of flash, the only problem is speed. I will be changing these parameters quite a bit in the application. That is why battery backed ram is the perfect solution. The last entry in the parameters must be preserved over reset or power on. I have done this on other platforms. So my question still stands, is there a way to prevent a section from being erased?

Bob

Robert:

Have you actually proven that SRAM is erased when only the (external?) SRAM is battery backed?

I presume you are referring to outboard SRAM as I would think a battery would continue to power a processor with RAM and that the two cannot be separated.

Maybe it's time the TI folks added the FRAM (MSP430 innovation) to the CORTEX line. FRAM = Ferrite RAM.

BTW: I tested other CORTEX processors and found the contents to be random after power up.

I guess your saying that If I connect a battery to the micro, the ram will not be preserved?

Bob

I'm referring to internal SRAM. I thought it would be preserved if I install a battery.

Bob

I think that is exactly what I said -- That SRAM would be preserved if you power the processor by standby battery.

However on Power UP (i.e. it must have been off) -- then SRAM contents will be RANDOM. If this is the case then clearly there is no built in routine that is "setting the values on startup/reset".

So a RESET should not change RAM values -- except as dictated by the program.

So if you write a small program that zeroes the RAM -- then reload with a minor change that does nothing (just loops) on startup  the RAM should not change on reset -- if the MCU remains powered.

You could change the contents to "FF's" and the result should be the same -- make the minor change so that RAM is no longer SET to "FF" -- reset -- there should be no change in the RAM.

This is all easily testable

Robert Keyes said:

first thought of flash, the only problem is speed.

Just dawned - why not employ MCU SRAM during your, "quite a bit" of application updates?  Then - when such SRAM activity halts/diminishes - simply copy that SRAM data-log into a "preset /readied" area of MCU Flash. 

In so doing - you've eliminated the requirement of battery, hibernate set-up/management - and any uncertainty of SRAM activity during power-up/down...  Note: powering the MCU via battery will be "draining" unless your MCU provides hibernate pins/mode - and is carefully - so configured...

Cool idea. The only problem with that is if the power plug was pulled all data will be lost. By the way, in the linker if you set --zero_init=off then all uninitialized ram is not set to zero. This works well. Don't know what other problems this will cause yet.

Bob

Robert Keyes said:

if the power plug was pulled all data will be lost.

If yours was NASA/Life Support Application (both not authorized/recommended by most any MCU vendor) would agree that is significant.

In the real-world - suspect that is "minor - perhaps rare event" - and may be best managed by regular (and interleaved) "writes to Flash."  (beware - Flash does wear...)

Linker issue likely is maker dependent - thus your findings may not prove, "universal."

Another, "Re-DAWN!" - in the past we solved, "Just such, "Power Plug Pulled" by detecting imminent Loss of Power - switching in battery back-up - and then copying SRAM into non-volatile memory!  (which may not be MCU Flash - due to life issues)  We then - properly/orderly shut down the MCU - last program instruction, "Opened our battery connection..."

Verified Answer Tick perhaps now justified...

Another good suggestion.

Just a note- this is a medical Class II device. Not life threatening but I'm just being overly cautious. The SRAM will be used to store the last direction (CW, CCW)  a six axis robot was going. If power was lost I need to home the robot in the opposite direction it was going so I don't tear all the cables off.

Bob

Robert Keyes said:

Another good

Not great?  I'd "self-award" - just for interest/persistence/imagination displayed. 

Technique suggested has been proven - can gain further robustness via multiple MCUs processing/recording/logging - then voting/verifying upon power restoral. 

Proposal herein minimizes size/cost and "exercise" of safe/back-up power source - clearly achieves your design goals.  (cb1 departs...)

This same question arose on the MSP430 FLASH -- so I went to the specs and worked out the numbers -- for updating once a day it was 90 years plus... sooo it does not seem like a bad idea -- probably a good one.

That's my only addition to the idea. Work the numbers.

With battery backup it's a good idea -- the other catch can be the time the shutdown data loss occurred -- for various reasons -- you you might be raising issues of an RTC as well -- battery backed.

Robert,

Upon further investigation, the hibernate module on the LM4F232 might have what you need. There are 16 words of BBRAM that are available in the module. It can be configured to enter hibernate mode whenever VDD drops too low. Then, a small battery (CR2032 on the EK-LM4F232) can supply power for the HIB module on VBAT. At 1.6-5 uA hibernate current draw, that battery could last a long time.

I guess nobody else is going to mention this -- so ...

EEPROM
The LM4F120H5QR microcontroller includes an EEPROM with the following features:
■ 2Kbytes of memory accessible as 512 32-bit words
■ 32 blocks of 16 words (64 bytes) each
■ Built-in wear leveling
■ Access protection per block

■ Lock protection option for the whole peripheral as well as per block using 32-bit to 96-bit unlock
codes (application selectable)
■ Interrupt support for write completion to avoid polling
■ Endurance of 500K writes (when writing at fixed offset in every alternate page in circular fashion)
to 15M operations (when cycling through two pages ) per each 2-page block.

8.2.4.1 Functional Description
The EEPROM module provides a well-defined register interface to support accesses to the EEPROM
with both a random access style of read and write as well as a rolling or sequential access scheme.
A protection mechanism allows locking EEPROM blocks to prevent writes under a set of
circumstances as well as reads under the same or different circumstances. The password model
allows the application to lock one or more EEPROM blocks to control access on 16-word boundaries.
Important: The configuration of the system clock must not be changed while an EEPROM operation
is in process. Software must wait until the WORKING bit in the EEPROM Done Status
(EEDONE) register is clear before making any changes to the system clock.
Blocks

There are 32 blocks of 16 words each in the EEPROM. Bytes and half-words can be read, and
these accesses do not have to occur on a word boundary. The entire word is read and any unneeded
data is simply ignored. They are writable only on a word basis. To write a byte, it is necessary to
read the word value, modify the appropriate byte, and write the word back.

Each block is addressable as an offset within the EEPROM, using a block select register. Each
word is offset addressable within the selected block.

The current block is selected by the EEPROM Current

etc.

That might help...

Same for big brother...

EEPROM
The LM4F232H5QD microcontroller includes an EEPROM with the following features:
■ 2K bytes of memory accessible as 512 32-bit words
■ 32 blocks of 16 words (64 bytes) each
■ Built-in wear leveling
■ Access protection per block

etc...

Been down that road also. I plan on doing what you suggested. If main power is lost store the values in SRAM to the EEPROM. THis should work well

Thanks

As CB pointed out -- Leaving the bread crumb trail might be a good idea too...

I guess if you have a medical robot excavating somewhere you could well end up with "hamburger" if the trail is not accurate... :-(

Robert Keyes said:

If main power is lost

This horse - far too beaten imho - and lack of reward disenchants...

I have never suggested that power to your MCU be allowed to be, "lost."  You may lose robot power - I have advocated instead for a, "non-interruptible" power source for the MCU - which may sense loss of other power - and only remove power from the MCU - in a proper & controllable fashion - after "latest/greatest" data trail has been logged and verified...  Have also suggested multiple MCUs - and a voting mechanism - to best insure system robustness...  (and I have "never/ever" seen (nor heard) of such a high-rel system reliant on 2032 (or similar) power source...)

When I said loss of power I meant the 120volt main. There will be a UPS connected at which time when low power is detected a controlled shut down will take place.