EmbeddedRelated.com
Forums

Writing to Flash during power down

Started by Jeff June 2, 2005
Hello All
Has any body got any experience or comments on writing to Flash 
(MSP430169), just before power down. Im my application I am monitoring 
the input power supply, i.e. input to the  3.3v MSP supply regulator, 
and when I detect power down write to the user area of Flash (0x1000) 
the uptime, this flash area will have been pre-erased during initial 
programming, to reduce the time taken in writing four bytes. If this is 
too risky I wont do it. I know I could do a flash write every day, but 
I am trying to reduce the number of flash writes. From my testing I 
have not had a problem, but I would be interested in any comments or 
experiences.
Thanks in advance .

Jeff



Beginning Microcontrollers with the MSP430

I use a data segment of flash (128 bytes) and write as necessary, 
cycling back once I've filled the block. My tets on Flash have shown 
that the flash is resilient enough to do this. One system has a  1k 
block for time storage that stores every minute. My worry would only be 
sustaining the power long enough to write the data. My systems that use 
flash storage also take control of the power down cycle. The power off 
button merely informs the processor that power off is required. The 
actual power disconnection is managed by the micro using the SHDN pin of 
the regulator. That an adeqaute caps just in case somebody pulls the 
battery while running. But I only write 2 bytes. The trick is that, 
although you may want to store 4 bytes for time, assuming you are 
storing seconds, the higher word only changes every 1000+ minutes, thus 
I have a fast segment for storing the LSW and a slow segment for storing 
the MSW. In a real power loss situation the actual write only takes 
microseconds. I would be inclined to actively monitor power in using the 
comparator, rather than polling it.

cheers

Al

Jeff wrote:

>Hello All
>Has any body got any experience or comments on writing to Flash 
>(MSP430169), just before power down. Im my application I am monitoring 
>the input power supply, i.e. input to the  3.3v MSP supply regulator, 
>and when I detect power down write to the user area of Flash (0x1000) 
>the uptime, this flash area will have been pre-erased during initial 
>programming, to reduce the time taken in writing four bytes. If this is 
>too risky I wont do it. I know I could do a flash write every day, but 
>I am trying to reduce the number of flash writes. From my testing I 
>have not had a problem, but I would be interested in any comments or 
>experiences.
>Thanks in advance .
>
>Jeff
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


Thanks for the reply,
I am just in the process of scoping the supply rail, before the 3.3v 
regulator, and the time it takes for for me to see the dip, and 
enact the flash write. Unfortunately I have no control over when 
power is taken down, but your idea on the comparitor is  a good one.
Thanks Jeff.


--- In msp430@msp4..., Onestone <onestone@b...> wrote:
> I use a data segment of flash (128 bytes) and
write as necessary, 
> cycling back once I've filled the block. My tets on Flash have 
shown 
> that the flash is resilient enough to do this. One
system has a  
1k 
> block for time storage that stores every minute.
My worry would 
only be 
> sustaining the power long enough to write the
data. My systems 
that use 
> flash storage also take control of the power down
cycle. The power 
off 
> button merely informs the processor that power off
is required. 
The 
> actual power disconnection is managed by the micro
using the SHDN 
pin of 
> the regulator. That an adeqaute caps just in case
somebody pulls 
the 
> battery while running. But I only write 2 bytes.
The trick is 
that, 
> although you may want to store 4 bytes for time,
assuming you are 
> storing seconds, the higher word only changes every 1000+ minutes, 
thus 
> I have a fast segment for storing the LSW and a
slow segment for 
storing 
> the MSW. In a real power loss situation the actual
write only 
takes 
> microseconds. I would be inclined to actively
monitor power in 
using the 
> comparator, rather than polling it.
> 
> cheers
> 
> Al
> 
> Jeff wrote:
> 
> >Hello All
> >Has any body got any experience or comments on writing to Flash 
> >(MSP430169), just before power down. Im my application I am 
monitoring 
> >the input power supply, i.e. input to the 
3.3v MSP supply 
regulator, 
> >and when I detect power down write to the user
area of Flash 
(0x1000) 
> >the uptime, this flash area will have been
pre-erased during 
initial 
> >programming, to reduce the time taken in
writing four bytes. If 
this is 
> >too risky I wont do it. I know I could do a
flash write every 
day, but 
> >I am trying to reduce the number of flash
writes. From my testing 
I 
> >have not had a problem, but I would be
interested in any comments 
or 
> >experiences.
> >Thanks in advance .
> >
> >Jeff
> >
> >
> >
> >
> >.
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >
> >
> >  
> >



i used an adm69x on the power supply and a big cap
the reset signal from adm was used to trigger an ext int who's only job was
to write big chunk in flash 
 
avram

Jeff <jeff_allan@jeff...> wrote:
Thanks for the reply,
I am just in the process of scoping the supply rail, before the 3.3v 
regulator, and the time it takes for for me to see the dip, and 
enact the flash write. Unfortunately I have no control over when 
power is taken down, but your idea on the comparitor is  a good one.
Thanks Jeff.


--- In msp430@msp4..., Onestone <onestone@b...> wrote:
> I use a data segment of flash (128 bytes) and
write as necessary, 
> cycling back once I've filled the block. My tets on Flash have 
shown 
> that the flash is resilient enough to do this. One
system has a  
1k 
> block for time storage that stores every minute.
My worry would 
only be 
> sustaining the power long enough to write the
data. My systems 
that use 
> flash storage also take control of the power down
cycle. The power 
off 
> button merely informs the processor that power off
is required. 
The 
> actual power disconnection is managed by the micro
using the SHDN 
pin of 
> the regulator. That an adeqaute caps just in case
somebody pulls 
the 
> battery while running. But I only write 2 bytes.
The trick is 
that, 
> although you may want to store 4 bytes for time,
assuming you are 
> storing seconds, the higher word only changes every 1000+ minutes, 
thus 
> I have a fast segment for storing the LSW and a
slow segment for 
storing 
> the MSW. In a real power loss situation the actual
write only 
takes 
> microseconds. I would be inclined to actively
monitor power in 
using the 
> comparator, rather than polling it.
> 
> cheers
> 
> Al
> 
> Jeff wrote:
> 
> >Hello All
> >Has any body got any experience or comments on writing to Flash 
> >(MSP430169), just before power down. Im my application I am 
monitoring 
> >the input power supply, i.e. input to the 
3.3v MSP supply 
regulator, 
> >and when I detect power down write to the user
area of Flash 
(0x1000) 
> >the uptime, this flash area will have been
pre-erased during 
initial 
> >programming, to reduce the time taken in
writing four bytes. If 
this is 
> >too risky I wont do it. I know I could do a
flash write every 
day, but 
> >I am trying to reduce the number of flash
writes. From my testing 
I 
> >have not had a problem, but I would be
interested in any comments 
or 
> >experiences.
> >Thanks in advance .
> >
> >Jeff
> >
> >
> >
> >
> >.
> >
> > 
> >. 


__________________________________________________
 




The way I understand what you are doing is that when the micro powers up
it will read the flash into ram.  It will then erase the ram.  Whenever
a power down situation occurs this data gets written back into flash.
Is this correct?

If it is you need to watch out for resets. If a RST or watchdog reset
fires you will loose any data that was not stored in flash.  Ideally
this should never occur, but can you guaranty that a reset will never
occur?

-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf
Of Jeff
Sent: Thursday, June 02, 2005 1:58 AM
To: msp430@msp4...
Subject: [msp430] Writing to Flash during power down

Hello All
Has any body got any experience or comments on writing to Flash 
(MSP430169), just before power down. Im my application I am monitoring 
the input power supply, i.e. input to the  3.3v MSP supply regulator, 
and when I detect power down write to the user area of Flash (0x1000) 
the uptime, this flash area will have been pre-erased during initial 
programming, to reduce the time taken in writing four bytes. If this is 
too risky I wont do it. I know I could do a flash write every day, but 
I am trying to reduce the number of flash writes. From my testing I 
have not had a problem, but I would be interested in any comments or 
experiences.
Thanks in advance .

Jeff




.

 
Yahoo! Groups Links



 

>Has any body got any experience or comments on writing to Flash
>(MSP430169), just before power down.

Yes, I do.  And although I have done it sucessfully, I would have to say I 
would not advise it.  It is tricky to get things just right such that the 
data is properly stored.  I have tried erasing and writing on power down, 
which takes a long time, but maintains FLASH intact.  I have also tried 
reading FLASH on power up, erasing it, and writing it only on power down.  
The latter method is is the fastest and requires the least amount of 
stay-alive time at power down but it is VERY risky.  If ANYTHING causes an 
unexpected interrupt, you have no saved data, just an erased FLASH.  Some 
would argue that internal RAM is preserved on an unexpected reset, but most 
compilers will zero RAM on startup.   And even if it was intact, there is no 
guarantee a multi-byte data write was completed before the reset.

Either way you do it, you must guarantee you can write the FLASH before the 
supply voltage drops below 2.7V (or whatever your minimum FLASH write 
voltage is).  Although you might be able to pick a capacitor or something 
that will keep the supply up long enough, you have to ask if it will behave 
any differently as the parts age, and over varying temperatures, etc.  It's

risky.

I would advise using some kind of true non-volatile, multi-writeable memory 
like an FRAM, and update its memory as values change, instead of storing 
everything on power down.  After all, the only reason you are writing only 
on power down is to conserve the FLASH write count.  With an FRAM, that is 
not a concern so you can write as often as you want.

Another poster said he used a power off button as a signal to the micro to 
turn power off using the shutdown of the regulator.  That is fine for normal 
powering down, but what about unexpected resets?  Believe me, they happen.  
One could argue that a reset could occur during the write of an FRAM too and 
that is true.  (BTW, that is true for any storage device, even internal 
RAM).  So, whenever you write, you should have some sort of redundancy 
involved (details purposely omitted here).

Choose the method you think is best.  I just found the power-down write 
timing game to be too risky.

Lou



Hi,

> If ANYTHING causes an 
> unexpected interrupt, you have no saved data, just an erased FLASH.  

is it also possible with an external EEPROM like 24AA16SN?

With some devices there is the problem that sometimes the external EEPROM
on an MSP430F149 (with software-I2C) suddenly gets empty but there is  no
obvious
reason for this.

Regards,

Rolf



Hi Rolf,
 
It is almost impossible for an EEPROM to be erased by an unexpected interrupt. 
 
Even a power interruption or EM interference can not affect the data inside the
EEPROM, unless the Program Counter of your MCU unexpectedly jumps to a memory
location including your Eeprom routines.
 
Regards,
Bahadir


rolf.freitag@rolf... wrote:Hi,

> If ANYTHING causes an 
> unexpected interrupt, you have no saved data, just an erased FLASH.  

is it also possible with an external EEPROM like 24AA16SN?

With some devices there is the problem that sometimes the external EEPROM
on an MSP430F149 (with software-I2C) suddenly gets empty but there is  no
obvious
reason for this.

Regards,

Rolf




.





---------------------------------
. 



		
---------------------------------
Discover Yahoo!
 Have fun online with music videos, cool games, IM & more. Check it out!






Hi,

> It is almost impossible for an EEPROM to be erased
by an unexpected interrupt. 
>  
> Even a power interruption or EM interference can not affect the data inside
the EEPROM, 
> unless the Program Counter of your MCU unexpectedly jumps to a memory
location including your Eeprom routines.

and what when power down happens during a write?
Can it be that the whole EEPROM gets empty or only at the specified address?
I think it's possible because during power down you get outside the
specifications.

Regards,

Rolf



Writing to Flash during power down

This is where the NMI input comes in. The Reset pin has two functions, ~RST and
NMI. On first power up the pin acts as an active-low reset, such that when the
input rises towards Vcc on application of power or from an external reset chip
the MSP430 cpu starts up. Subsequently the user modifies this pin to be an NMI,
which when it subsequently generates an interrupt will set a flag or otherwise
indicate to the main software that a power loss is imminent and that the Flash
must be written immediately. The trick is to generate the ~RST/NMI signal such
that it occurs before the power is really lost to the MSP430. By design this
can be guaranteed to occur (say) 10 mSecs before the power on the MSP430 cpu
drops below the minimum voltage required to write the Flash (typically 2.7V).

Once the software is running, this pin is changed to the NMI function by
modifying WDTNMI in WDTCTL. The active edge of the NMI interrupt is set by
WDTNMIES. Typically you would use a falling edge so that the same active-low
signal can provide both the Reset function and the NMI function. Usually an
external Reset/Power Monitor chip would be used to provide this, since they can
typically be set to trip at a specific voltage (perhaps 2.9V or 3.0V). There
are dozens of available types.

Now when the NMI interrupt occurs the user simply has to write out all Flash
data that has to be saved in the time available before the voltage collapses
below the critical 2.7V level. Just be sure to make the hold-up time long
enough to ensure this, bearing in mind the flash write itself might consume up
to 5mA when it pulses. Easiest way to do this is to provide sufficient
capacitance to ensure the Vcc takes (say) 10msecs to fall from (say) 3.0V to
2.7V. The higher you set the starting trip voltage for the power fail function,
the less capacitance you require. A few uF is usually sufficient, and if you
respond quickly and don't write a lot of data a much shorter hold-up time
is
required.

Use the following formula, where Vo is the end voltage (2.7V), V is the trip
voltage, t is the hold-up time required and R is the equivalent resistance of
the MSP430 and whatever else is on the rail (approximate by volt/current). C is
the required capacitance.

  Vo = Ve(-t/CR)
So:
  C = -t/(RLn(Vo/V))

There are better schemes to allow more time with less capacitance, which just
involve sensing the source voltage closer to the supply. Typically this might
be loss of AC in a line-powered application, or removal of the battery cover in
a handset.

One last point: once you hit the NMI interrupt remember to immediately power
down anything that uses significant power before writing the Flash and remember
to freeze the cpu once finished (you don't want to return back to normal
operation until the cpu gets reset).

Hugh

--- rolf.freitag@rolf... wrote:

> Hi,
> 
> > It is almost impossible for an EEPROM to be erased by an unexpected
> interrupt. 
> >  
> > Even a power interruption or EM interference can not affect the data
inside
> the EEPROM, 
> > unless the Program Counter of your MCU unexpectedly jumps to a memory
> location including your Eeprom routines.
> 
> and what when power down happens during a write?
> Can it be that the whole EEPROM gets empty or only at the specified
address?
> I think it's possible because during power down you get outside the
> specifications.
> 
> Regards,
> 
> Rolf
> 
> 
>