Hello Jeff,

Although I never did that on an MSP I have designed circuits with
similar functions. The trick to make the scenario reliable is to
supply enough energy for the write operation to complete. Usually that
involves a detect circuit, a capacitor and a regulator.

The detection is easy, I often use a TLV431 and some cheap logic to
watch out. The refs on the MSP may not be good enough but I am not
sure about that.

The cap needs to be large enough. Take into account aging of
electrolytics here, so be generous. The regulator may have to be a
switcher in this case unless your power originates from a mains supply
in which case you could tap off before the regulator of that supply.
Then you'd get away with a simple linear regulator.

IOW, after an outage detect the MSP needs to see a clean Flash level
supply voltage for as long as it takes to complete the write operation
under worst case conditions.

Regards,

Joerg.

Thanks for the suggestions. I am sensing the incoming supply using the 
onboard A-D,  this supply is then fed to a 3.3v regulator via a diode, 
so in effect the MSP supply is isolated. I appear to have enough time 
under all circumstances, but I know that once you set the write 
password, to enable flash write, untill the write has been completed 
and lock put back on, there is that risk that if power down happens 
during this time, I could write over different part of flash memory.
Interesting point Rolf made about freezing CPU after my flash write in 
power down mode.
I must say that the TI flash write/read cycle seems to be quite 
reliable under normal circumstances, i.e. not the mode I am 
comtemplating.
Thanks for the response's.

Jeff

Hello Jeff,

>                       ... I appear to have enough
time 
> under all circumstances, but I know that once you set the write 
> password, to enable flash write, untill the write has been completed 
> and lock put back on, there is that risk that if power down happens 
> during this time, I could write over different part of flash memory.

That is where the capacitor comes in. In the same way that classical
hospital backup power systems contain a large flywheel which keeps
things humming long enough to start the Diesel.

If you had a diode before the large electrolytic (Schottky if the
overhead is a bit on the low side) you can sense the voltage before
the diode. If there isn't another large cap at that node you'd have to
peak-sample. Now if that voltage drops the capacitor will keep the
other side up for a while. It just has to be large enough plus a lot
of reserves. Also, it needs to be able to stay above the desired
voltage plus the regulator drop-out voltage.

Regards,

Joerg.

All of the discussion here has assumed that the micro is functioning and
there was a loss of AC power.  This is all well and good, but what
happens if something else causes the micro to reset.  I've seen spikes
as short as 10nSeconds lock up MSP430's.  If somehow a transient like
this gets into your board, and you don't already have the flash written
then you could loose the data.  Worst case, I've seen the micro
completely locked up with no chance to save the data.  An external
Watchdog would bring it back life but not if it was configured as a
nonmaskable interrupt.  If I understand the way these work correctly,
the micro needs to still be functioning in some logical manner to do a
controlled restart.

Yes, we have been burned by this before.  I would not trust writing to
RAM upon power down in any situation where the data was in any way
important or noticeable by the end user.  At some point in time you will
loose data.

Dan M

-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf
Of Joerg Schulze-Clewing
Sent: Thursday, June 02, 2005 3:15 PM
To: msp430@msp4...
Subject: [msp430] Re: Writing to Flash during power down

Hello Jeff,

>                       ... I appear to have enough
time 
> under all circumstances, but I know that once you set the write 
> password, to enable flash write, untill the write has been completed 
> and lock put back on, there is that risk that if power down happens 
> during this time, I could write over different part of flash memory.

That is where the capacitor comes in. In the same way that classical
hospital backup power systems contain a large flywheel which keeps
things humming long enough to start the Diesel.

If you had a diode before the large electrolytic (Schottky if the
overhead is a bit on the low side) you can sense the voltage before
the diode. If there isn't another large cap at that node you'd have to
peak-sample. Now if that voltage drops the capacitor will keep the
other side up for a while. It just has to be large enough plus a lot
of reserves. Also, it needs to be able to stay above the desired
voltage plus the regulator drop-out voltage.

Regards,

Joerg.




.

 
Yahoo! Groups Links



 

you are omitting one simple option. A write buffer. The OPonly wants to 
write time as 4 bytes (it can be written as 2). so a buffer is usd. On 
power up the next empty word is found, erase is only needed if that word 
is the buffer end, when it can be copied to the buffer start, after 
first erasing the buffer segment. Flahwrites are so fast on the MSP430 
that even without extra capacitance it is hard to fail a single word 
write, given a fast power loss detection method. This is the real key to 
success.

Al

Lou C wrote:

>>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
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

This is becoming a rarer event. At one time EEPROJM did this all too 
often. It shouldn't happen with modern EEPROM. I ALWAYS make the WP 
explciitly protect except when I need to write the memory. I pull the WP 
pin high in case of some micro failure. I make sure my system and power 
supplies aren't noisy. I have never had these problems with newer ST 
memory, or Atmel serial Dataflash.

Al

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
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Hello Dan,

> All of the discussion here has assumed that the
micro is functioning and
> there was a loss of AC power.  This is all well and good, but what
> happens if something else causes the micro to reset.  I've seen spikes
> as short as 10nSeconds lock up MSP430's. ...

Then I'd try to figure out how that spike got there. 10nsec is pretty
serious. I have to deal with this topic a lot and mostly it is due to
ground plane issues or suboptimal decoupling. Usually the fix requires
a relayout.

The only scenario I could see where spikes can't really be controlled
is lightning (very close hit that typically fries a lot) and
spacecraft (radiation hits).

Regards,

Joerg.

The spikes appear to be coupling in across some relays that are
controlling motor contactors that are in turn controlling large AC
motors.  This probably appears somewhere in the archives as well.  We've
added snubbers to kill the spikes and have gotten rid of them but the
fact still exists that if the micro does lock up for some reason you may
loose data if the timing is bad.

I do like Al's method of the buffer though.  Simple solution that's
saves the data just in case of a reset.

-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf
Of Joerg Schulze-Clewing
Sent: Thursday, June 02, 2005 5:12 PM
To: msp430@msp4...
Subject: [msp430] Re: Writing to Flash during power down

Hello Dan,

> All of the discussion here has assumed that the
micro is functioning
and
> there was a loss of AC power.  This is all well
and good, but what
> happens if something else causes the micro to reset.  I've seen spikes
> as short as 10nSeconds lock up MSP430's. ...

Then I'd try to figure out how that spike got there. 10nsec is pretty
serious. I have to deal with this topic a lot and mostly it is due to
ground plane issues or suboptimal decoupling. Usually the fix requires
a relayout.

The only scenario I could see where spikes can't really be controlled
is lightning (very close hit that typically fries a lot) and
spacecraft (radiation hits).

Regards,

Joerg.




.

 
Yahoo! Groups Links



 

Jeff, you need to consider a Brown Out also. What happens if you think
there
is a Power Fail conditiopn, you start the data store procedure but half way
through it
power comes back ?

This can repeat it self many times a second, in effect simulating an
oscilation of the power supply .

In one of our designs we have inserted a power relay (a power FET) in series
with the power line. Once our harware made the decision to go in Power Fail
Mode
the processor turned off the power FET and keept it this way until all was
done.

Good luck :)

Alex

----- Original Message -----
From: "Jeff" <jeff_allan@jeff...>
To: <msp430@msp4...>
Sent: Thursday, June 02, 2005 2:52 PM
Subject: [msp430] Writing to Flash during power down


> Thanks for the suggestions. I am sensing the
incoming supply using the
> onboard A-D,  this supply is then fed to a 3.3v regulator via a diode,
> so in effect the MSP supply is isolated. I appear to have enough time
> under all circumstances, but I know that once you set the write
> password, to enable flash write, untill the write has been completed
> and lock put back on, there is that risk that if power down happens
> during this time, I could write over different part of flash memory.
> Interesting point Rolf made about freezing CPU after my flash write in
> power down mode.
> I must say that the TI flash write/read cycle seems to be quite
> reliable under normal circumstances, i.e. not the mode I am
> comtemplating.
> Thanks for the response's.
>
> Jeff
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hello Dan,

> The spikes appear to be coupling in across some
relays that are
> controlling motor contactors that are in turn controlling large AC
> motors.  This probably appears somewhere in the archives as well. 
We've
> added snubbers to kill the spikes and have gotten rid of them but the
> fact still exists that if the micro does lock up for some reason you may
> loose data if the timing is bad.

I remember a thread about that a while ago. Maybe you could post a
schematic?

Thing is, this could also cause erroneous operation if the micro
stumbles at a critical routine. Even if it doesn't stall out it might,
for example, mis-interpret a feedback value. Depending on what those
motors drive that can create some grief.

The grounding scheme is typically the first place to look. That sounds
easier than it is though. Worst case you could use optocouplers or
pulse transformers but that might feel a bit like curing the symptoms.

The other challenge is to measure spikes in the first place. Often the
EMI around the unit is so serious that the scope shows spikes without
the probe being connected to anything. That would be where little
current transformers come in.

Regards,

Joerg.