Hello Alex,

> 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 could be done without much hardware, similar to the routines
radio transmitters use after the mast got hit. Most of them perform a
few sanity checks and restart attempts before shutting down the
transmitter for good. Same with some UPS units.

It might work like this:

- Power dip is detected.
- Data is written to Flash.
- See if power still low.
- If power low, wait in a chosen dormant state.
- If power ok, do several checks whether it stays on.
- If it stays on, check capacitor charge.
- Repeat capacitor check until sufficient.
- Once capacitor charge is above margin, wake up and continue.

It all depends on what the particular micro controls but with the nice
low power modes the MSP430 should be particularly suited to handle
such tasks.

Regards,

Joerg.

I do almost the same as Alex but at software stand point. Maybe it is
easier
when using assembler language. Once the power failure is detected the
firmware enters in a Goto_Lowpower mode where all necessary data is written
to the Flash and LPM3 is switched. Then once every 10 seconds I wake-up to
sense external power that has to be above some limit where I know capacitors
will hold enough energy to be able to return from low power.

Of course this works fine when you have a battery in the system. Otherwise I
would use a supervisor with very long RESET timming in order to keep CPU in
reset in case PSU is oscillating (again, a detailed design specification
must be made to cover all possibilities). Also in this case, when detecting
power failure, software would save data in FLASH and enter in a loop waiting
for hardware reset.
You could sense power while in the loop and measure active supply time to
decide if it is safe to return to main routine without waiting for hardware
RESET (that may never comes).
Along with all posts in this thread I hope this will also help in your
design.

-Augusto


-----Original Message-----
From: msp430@msp4... [HYPERLINK
"mailto:msp430@msp4..."mailto:msp430@msp4...] On Behalf Of
alex@alex...
Sent: Thursday, June 02, 2005 7:20 PM
To: msp430@msp4...
Subject: Re: [msp430] Writing to Flash during power down


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
>
>
>
>
> .
>
>
> "http://docs.yahoo.com/info/terms/





-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 1/6/2005
 

> you are omitting one simple option. A write buffer.

I was going to suggest something similar, which is an old
database technique... use double buffering. On startup,
read from the buffer containing the newest data, and erase
the other one. Write to the erased one on shutdown, with
an incremented update-number. Even if the shutdown fails
save the data, the previous copy will be ok and may be
sufficient for a valid restart.

Clifford Heath.

P.S.
Wrt token ring, you can't simply say "it's better". Some
environments require guaranteed maximum latency, and
some want maximum average throughput. Guess which one
suits office PCs? But token ring is cooler than many folk
give it credit for, Alex is right about that.

Thanks for all the  feedback on the subject, It looks like a few of you 
have been through this loop before. It also looks to me that on the 
MSP430 wish list is a seperate Flash area for data (or two), that is 
protected from program memory would be useful. So in the event of data 
corruption (checksummed)to this seperate data area you could look at a 
second back up copy which be from main program memory or this second 
data area, and I am talking a few hundred bytes here.
Do you think anyone from TI reads this forum :-) ?

Jeff

Hi Rolf,
 
I previously designed some systems, which faced unexpected power down
frequently.
 
I used the method of triple-writing, means writing the same data to three
different blocks in EEPROM.
 
After the power is stable again, I check these three blocks and compare. Usually
I see that all three blocks are the same and including correct data. 
 
It was rarely to appear that one of the blocks is corrupted (when the situation
you told happens : power down was during a write cycle to EEPROM), so I use the
reliable data which was read the same in the other two unaffected blocks.
 
Following are the cases to be happen during initialization after a power down:
 
1- All three blocks have the same data --> All three blocks have the LAST
data written.
2- First two blocks are same, third is different --> Data corrupted during
the write cycle to the third block. The LAST data is held in the first two
blocks.
3- The second and third blocks are same, first block is different --> Data
corrupted during the write cycle to the first block. You have the PREVIOUS
written data in second and third blocks. The LAST data may be corrupted.
 
4- All three blocks have different data --> Data corrupted during the write
cycle to second block. In this case, first block includes the LAST written data
which was during power down, third block includes the PREVIOUS written data. 
 
I have never faced a data corruption problem with this method. I suggest you to
use the same method if you have CRITICAL and SMALL data blocks to be saved
regularly. 
 
Best Regards,
Bahadir
 

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




.





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


__________________________________________________
 

Hi,

msp430@msp4... schrieb am 03.06.05 08:44:14:
> 
> Thanks for all the  feedback on the subject, It looks like a few of you 
> have been through this loop before. It also looks to me that on the 
> MSP430 wish list is a seperate Flash area for data (or two), that is 
> protected from program memory would be useful. So in the event of data 
> corruption (checksummed)to this seperate data area you could look at a 
> second back up copy which be from main program memory or this second 
> data area, and I am talking a few hundred bytes here.

as Bahadir said, you do need 3 blocks because with only two you can't find
out
where damaged and not damaged data are. A checksum is not enough because
of checksum collisions, e. g. md5sum collisions, and if also the data and the 
checksum are corrupted the corrupted checksum can the checksum of the corrupted
data. Another problem of checksums is the additional code, CPU time and space
for the checksum.


> Do you think anyone from TI reads this forum :-) ?

You should look at the email addresses of the mails from this list  ;-)

Regards,

Rolf

This created some real headaches around here for awhile.  We tracked
down the noise source to the motor contactors.  When the coils were
released on these we could measure 400V (on a 120VAC line )peak to peak
swings in less than a microsecond.  Putting snubbers across the coils
eliminated these spikes.  Running the units at -40 degrees tended to
make things worse.

The spikes are now gone and testing has shown that the problems are gone
as well.  I am a firm believer though in that if anything can happen it
will.  Usually at the worst point in time.  Watchdogs then become a
must.  They are only a last resort when everything else has failed and
nothing can be trusted.
-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf
Of Joerg Schulze-Clewing
Sent: Thursday, June 02, 2005 6:54 PM
To: msp430@msp4...
Subject: [msp430] Re: Writing to Flash during power down

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.




.

 
Yahoo! Groups Links



 

but dont you also then need to do three segment erases during this process
and therefore this is not too nice as a power-down routine?

  _____  

From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
rolf.freitag@rolf...
Sent: 2005. jius 3. 11:28
To: msp430@msp4...
Subject: Re: [msp430] Writing to Flash during power down


Hi,

msp430@msp4... schrieb am 03.06.05 08:44:14:
> 
> Thanks for all the  feedback on the subject, It looks like a few of you 
> have been through this loop before. It also looks to me that on the 
> MSP430 wish list is a seperate Flash area for data (or two), that is 
> protected from program memory would be useful. So in the event of data 
> corruption (checksummed)to this seperate data area you could look at a 
> second back up copy which be from main program memory or this second 
> data area, and I am talking a few hundred bytes here.

as Bahadir said, you do need 3 blocks because with only two you can't find
out
where damaged and not damaged data are. A checksum is not enough because
of checksum collisions, e. g. md5sum collisions, and if also the data and
the 
checksum are corrupted the corrupted checksum can the checksum of the
corrupted
data. Another problem of checksums is the additional code, CPU time and
space
for the checksum.


> Do you think anyone from TI reads this forum :-) ?

You should look at the email addresses of the mails from this list  ;-)

Regards,

Rolf




.





  _____  

> . 

Rolf,

> as Bahadir said, you do need 3 blocks because with
only two 
> you can't find out
> where damaged and not damaged data are. A checksum is not 
> enough because
> of checksum collisions, e. g. md5sum collisions, and if also 
> the data and the 
> checksum are corrupted the corrupted checksum can the 
> checksum of the corrupted
> data.

MD5 and SHA-1 digests collide very, very infrequently and they're
designed that way for digital signatures.  If SHA-1 doesn't fulfil your
needs, there are other FIPS SHA variants, SHA-256 and SHA-512 that are
even less likely to collide.

-- Paul.

Hi,

> MD5 and SHA-1 digests collide very, very
infrequently and they're

yes, but they are not absolutely safe. I have some files with only 128 byte
which
are different and do have the same md5sum.
It's saver to use md5sum and sha1sum but that only increases the
probability which will
always be smaller than exactly 1. 
I do prefer exactly 1 and not nearly 1; checksums are good in some cases but
often not
good enough (snake oil), especially when you have a safe alternative.

Regards,

Rolf