Hi all,

Since requests were made for MSP430 talks, here we go.

A question on my mind for some time has been what its Flash endurance
is like at highest commercial temperatures (say 70 degr C)
These things seem to be a bit avoided.
I know it's way less than 100K EW cycles.

Anyone ever done any experiments ?
Al ? You seem to be the guru on pushing the envelope on MSP430 -
have you done tests like that ?

Cheers,
Kris

microbit wrote:
> 
> Hi all,
> 
> Since requests were made for MSP430 talks, here we go.
> 
> A question on my mind for some time has been what its Flash endurance
> is like at highest commercial temperatures (say 70 degr C)
> These things seem to be a bit avoided.
> I know it's way less than 100K EW cycles.
> 
> Anyone ever done any experiments ?
> Al ? You seem to be the guru on pushing the envelope on MSP430 -
> have you done tests like that ?
> 
> Cheers,
> Kris
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/

40 DEGC is the highest I can sustain for prolonged periods. I can tell
you that a couple of hours in my oven set to just under 100DEGC, and
fluctuating somewhat between 80 and 95 set on a single segment writing
words until the block was filled, then erasing, while doing the same
bytewise on a separate segment, saw no failures in the byte segment and
only 1 failure (which subsequently recovered) in the word segment The
sequence ran every second, erasing the segment at the start of the run,
checking all values were 0FFFFH, then writing the segment and again
checking the values were all correct. I ran 4000 cycles, which was all I
was interested in. In my deep freeze I saw 4 word and 3 byte errors, all
recovered. 

I have a long term test running on top of our gas heater (it's winter
here and 15degc seems freezing to me!) to trial some code for a pending
project. It writes a block of 8 words every 10 seconds in an 8k block of
flash. When it writes the last block it erases all segments and starts
again. Alternate loops through the flash I invert the data that is being
written. I am effectively life testing it. I experienced some problems
after a week, that turned out to be low supply voltage. Basically the
flash is re-written every 2.84 hours. Since it is not particularly
thermally stressed (although temperature is rexorded, and has been as
high as 60C when I forgot to turn the heater fan on, and as low as 6C
overnight, it doesn't really meet your needs. However it is a real world
test. The target system will operate for typically 10 hours a week, with
a life expectancy of 10 years maximum, saving data once every minute, so
5000 hours of running or 300000 saves or 293 cycles through the flash
block. To emulate this I need to run for 34.7 days, I am at day 70 now,
with a total of 7 errors that were correctable by the program. My
software does not rely on correct programming every time, it tests the
value, and, in the event of a failure attempts to re-write that word, if
the failure was simply a failure to set the bit to '0' from its
default
'1' state, ie I try to re-program the same word. If that fails it
flags
a persistent  error. There are none so far.

My findings to date regarding FLASH integrity.

Flash programming is very sensitive to low supply voltage. I would
recommend keeping the voltage at a MINIMUM 3.0V for this. Don't use a
lithium cell directly, the voltage droops too much. lithium ion or
Lithium Poly are better but I prefer to use a dc/dc converter if
possible.

I had more problems at low temperature than high, but my tests are very
limited, just one system each. Most failures I have seen have been
failures to 'take', and not necessarily hard filures, it seems as if
the
programming cycle can sometimes be a bit borderline for some reason. No
idea why, but suspect power supply and possibly noise issues.

The flash appears to be more robust than I expected it to be. I have
board shere that I use for all sorts of quick and dirty tests. One of
these in particular has been in constant use for over 2 years, and has
probably been reprogrammed several thousand times, because I am lazy and
leave Kickstart set to download the lates file every time I open it. It
is still going strong. While I've been typing it has run through and
tested that every word in flash can be erased then written to 0000H then
erased again.

Al

Thanks Al,

I am very grateful for this info.
My main concern was the high side of Temp.
To clarify our terminolgies :

Say, If I erase 1 sector but then write 200 bytes -
do you count that as
- 1 cycle
- or 200 cycles.

My figures take the terminology for what it should be.
Scenario (1) - ie. 1 EW cycle.
(I might eg. erase a sector 6 times, but only "change" 4 words)

I'm trying to design a better Flash File system than what I have now, but
the code's
already complex enough, believe you me !!


Thanks a lot Al.

Kris

> Say, If I erase 1 sector but then write 200 bytes -
> do you count that as
> - 1 cycle
> - or 200 cycles.

I asked TI support this question some weeks ago.
The answer: It's 1 cycle

Wolfgang

> I asked TI support this question some weeks ago.
> The answer: It's 1 cycle

Thanks Wolfgang.
I wanted to make sure we were all talking the same "language".
I was mainly concerned with any experiences on high temperatures, as 
these things are avoided a bit.
Try and get a guaranteed figure @ temp 70 degr C - hmmm.

Rgds
Kris

microbit wrote:
> 
> Thanks Al,
> 
> I am very grateful for this info.
> My main concern was the high side of Temp.
> To clarify our terminolgies :
> 
> Say, If I erase 1 sector but then write 200 bytes -
> do you count that as
> - 1 cycle
> - or 200 cycles.

1 cycle. Or should I be pedantic and say 200/512ths of a cycle ;@}

> 
> My figures take the terminology for what it should be.
> Scenario (1) - ie. 1 EW cycle.
> (I might eg. erase a sector 6 times, but only "change" 4 words)
> 
> I'm trying to design a better Flash File system than what I have now,
but
> the code's
> already complex enough, believe you me !!
> 
> Thanks a lot Al.
> 
> Kris

I don't know what you're looking at but my whole thing takes under 200
bytes of code. It isn't hugely complex, since the data is all fixed
record lengths, but it does a few smarts. unfortunately one of those
things that I won't part with.

Al

Theoretically Ti quote over the entire temperature range. In fact, with
most things I have found them to be extremely conservative with their
specifications. I would expect this, since a very conservative spec
reduces the likelihood of legal action. Not from you or I of course, we
have no clout, but from the guys who buy millions of these things and
have the money to be a threat.

I have no reason to doubt Ti's life specs, even though I do, due to old
age, cynicism and a little paranoia perhaps, neither do I have the
facilities or inclination to test them. Although I do push things i do
this only for things which interest me directly and specifically. Like
how do I get the MSP430 to execute 48 4 pole filters in real time at
8kHz sample rate. Answer? Not yet, but at 20Mhz I'm getting close. I
can't afford the current budget for a DSP.

Al

microbit wrote:
> 
> > I asked TI support this question some weeks ago.
> > The answer: It's 1 cycle
> 
> Thanks Wolfgang.
> I wanted to make sure we were all talking the same "language".
> I was mainly concerned with any experiences on high temperatures, as
> these things are avoided a bit.
> Try and get a guaranteed figure @ temp 70 degr C - hmmm.
> 
> Rgds
> Kris
> 
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/

Hi Al,

> I don't know what you're looking at but
my whole thing takes under 200
> bytes of code. It isn't hugely complex, since the data is all fixed
> record lengths, but it does a few smarts. unfortunately one of those
> things that I won't part with.

Don't need any code Al :-)

I'm trying to minimise fragmentation and Flash stress at the same time too.
I have variable record lengths though and dynamic allocation - like a
"heap",
but in Flash etc etc to break it up and sew it together again
(the pointers, not the actual data in the records) etc.
The biggest headache really was records that overlap sector boundaries.
Even just a 512 byte buffer is a stiff penalty on my RAM resources, but to
handle that
I ideally need 1024 bytes.
Solution could have been buffer it in Flash, right ? Can't either for more
other reasons,
and so it went on.

I wanted to approximate the worst cases of Flash wear, and it seemed to me
that it's at
the highest temperatures. (well that's what TI told me BTW)

It's a walk in the park in RAM - but Flash is the pits.
I think I'll leave it be and fine tune it more one fine day :-)

(I can't wait for the parts with lots more RAM :-)

I shouldn't complain though, because the MSP430's Von Neumann
architecture
is heaven sent.
I've ported the code onto a Harvard architecture - and it blows the code
way
out.
Things like expression evaluation/parsing and formatted Output on RAM and on
ROM sources need
separate (sub)funcs/modules bla bla.
On the MSP430, away you go - it's all the same code.
I only wish someone would have sacrificed a little current and put a bloody
bus controller
that rectifies word alignment errors, that would have made life easier.
Then again, a compiler/linker for it must be the pits in that regard...
Ask Paul, I'm sure he's very fond of MSP430's lack of bus sizing
:-)

microbit wrote:
> 
> Hi Al,
> 
> > I don't know what you're looking at but my whole thing takes
under 200
> > bytes of code. It isn't hugely complex, since the data is all
fixed
> > record lengths, but it does a few smarts. unfortunately one of those
> > things that I won't part with.
> 
> Don't need any code Al :-)
> 
> I'm trying to minimise fragmentation and Flash stress at the same time
too.
> I have variable record lengths though and dynamic allocation - like a
> "heap",
> but in Flash etc etc to break it up and sew it together again
> (the pointers, not the actual data in the records) etc.
> The biggest headache really was records that overlap sector boundaries.
> Even just a 512 byte buffer is a stiff penalty on my RAM resources, but to
> handle that
> I ideally need 1024 bytes.
> Solution could have been buffer it in Flash, right ? Can't either for
more
> other reasons,
> and so it went on.
> 
> I wanted to approximate the worst cases of Flash wear, and it seemed to me
> that it's at
> the highest temperatures. (well that's what TI told me BTW)

I suspect that my probelsm at lower temperatues may be related to
battery issues rather than FLASH itself, as I said  I set out only to
see if I could get a certain life out of them.

> 
> It's a walk in the park in RAM - but Flash is the pits.
> I think I'll leave it be and fine tune it more one fine day :-)
> 
> (I can't wait for the parts with lots more RAM :-)

1611 date appears to have slipped slightly, but Ti have started enroling
in the US for 169 courses. Naturally we in the boonies get left until
last. I too am waiting. I plan to standardise around the 1611 and 1232,
rather than the 149 and 1211.

> 
> I shouldn't complain though, because the MSP430's Von Neumann
architecture

Bugger and I thought it was an Alfred E. Neumann architecture.

> is heaven sent.
> I've ported the code onto a Harvard architecture - and it blows the
code way
> out.
> Things like expression evaluation/parsing and formatted Output on RAM and
on
> ROM sources need
> separate (sub)funcs/modules bla bla.
> On the MSP430, away you go - it's all the same code.
> I only wish someone would have sacrificed a little current and put a bloody
> bus controller
> that rectifies word alignment errors, that would have made life easier.
> Then again, a compiler/linker for it must be the pits in that regard...
> Ask Paul, I'm sure he's very fond of MSP430's lack of bus
sizing :-)

Don't tell the modern purists out there, they think weak typing is a
'bad thing'. 

Al

Hi Al,

> I suspect that my probelsm at lower temperatues
may be related to
> battery issues rather than FLASH itself, as I said  I set out only to
> see if I could get a certain life out of them.

I'm not dismissing something I asked for Al :-)
I'm grateful you were willing to share your observations, which I'm
sure
took
time/effort.
But the figures you mention are encouraging....

I haven't seen any datasheet that specifically stipulates a temperature
range
vis-a-vis Flash endurance. I know there's a reason but I don't know
what it
is -
I just want to know what the figures are - characterised - but that won't
happen
in a hurry.
So the next best thing for me is what you've accomplished so far.
Thanks again Al.

Cheers.