"Frank Buss" <f...@frank-buss.de> wrote in message
news:72ndybgghqlq$.lsk6ue9vauo3$.d...@40tude.net...
> What do you think of MRAM for critial applications? It's a bit expensive,
> but they claim data retention of minimum 20 years and unlimited number of
> writes. It is even used in a satellite:

I thought it was limited number of writes. But for certain packages (serial) it practically means
unlimited as the protocol limits number of reads sufficiently.

M 

"Jamie" <j...@charter.net> wrote in message
news:S3E4k.66$0...@newsfe05.lga...
> Joerg wrote:
>> What do you mean by strong? VHF radio close by? Cell phone? If yes, do you remember how close?
>>
>  100 W VHF transmitter ~ 6 feet away.

I would guess the part went haywire and started overwriting the flash
itself by some randomly executed code.  Possibly the fuses were not set or
were even ignored.

Mark 

TheM wrote:

> I thought it was limited number of writes. But for certain packages (serial) it practically means
> unlimited as the protocol limits number of reads sufficiently.

The Freescale chip has fast parallel access (35ns), like a slow SDRAM, and
this page says "Unlimited Write and Read Cycles":

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=4MBIT&nodeId=015424

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Jonathan Kirwan wrote:
> On Fri, 13 Jun 2008 16:23:42 -0700, Joerg
> <n...@removethispacbell.net> wrote:
> 
>> Jonathan Kirwan wrote:
>>> On Fri, 13 Jun 2008 15:42:27 -0700, Joerg
>>> <n...@removethispacbell.net> wrote:
>>>
>>>> Hello All,
>>>>
>>>> After some problems a client saw I was treated to my own dose of what is 
>>>> likely flash loss: The uC in our mailbox door has become erratic. I 
>>>> installed it about three months ago and half of the day it receives a 
>>>> good pelting from the sun. First it began not recognizing some keys, 
>>>> then it started doing weird stuff like lock cycling. Things it wasn't 
>>>> meant to ever do. Batteries, contacts and such look ok, reset didn't 
>>>> help, so that's not it.
>>>>
>>>> TI has an app note about the topic:
>>>> http://focus.ti.com/lit/an/slaa392/slaa392.pdf
>>>>
>>>> Figure 1 looks scary above the 80C range. Later they presented another 
>>>> test with a different bake cycle which makes things look better but who 
>>>> knows.
>>>>
>>>> What is you experience with respect to flash errors on uC that are 
>>>> exposed to elevated temperatures as most outdoors applications are?
>>> I only have some small experience here with the MSP430.  It seems to
>>> operate at 140C at 3V and 3.3V for the several-hour long tests I've
>>> done.  But some bad experiences in storing data into the flash at that
>>> temp and even at 3.3V and higher.  But I didn't need the darn thing to
>>> survive all that long, either.
>> Wow, problems within hours at 140C? Not cool :-(
> 
> No.  No problems, at all.  Just that I didn't run them for more than
> about 5 hours at a time.  Same one ran for weeks, though, at periodic
> elevated temperatures.  I was just collecting data from a rotating hot
> surface and wanted to just stick the whole contraption there while it
> stored a few bits of data into RAM.  The battery was the problem.
> 


However, you said "But some bad experiences in storing data into the 
flash at that temp and even at 3.3V and higher."


>>> I haven't read, for understanding, the data sheet you mentioned.  I
>>> just downloaded it, though, and thanks for pointing it up.  I think it
>>> wasn't around when I looked a few years back and I'm glad that you
>>> pointed it up for me.
>>>
>>> Your obvious solution is to move north about a thousand miles.  ;)
>> My wife would absolutely not do that.
> 
> Oregon is absolutely beautiful!  I've got pileated woodpeckers, 4
> kinds of squirrels including a flying squirrel (nocturnal), peafowl,
> chickens, guinea hens, turkeys and so on -- tall 60-80 year old firs,
> two kinds of ferns, rhododendrons that bloom in succession around the
> place, and it looks like a lush rain-forest national forest when you
> walk the paths on the property.  Lots of acres, 5000 sq ft home, 1/4
> mile driveway to the house, view of the mountains, 5 minutes to a
> hospital and 20 minutes to the PDX international airport, a 17 mile
> well-maintained walking and horse trail that goes from 1/2 mile away
> from my home to the Willamette River in Portland, and it cost me $330k
> in 2002.  Prices are still low, too.  Next door has been on the block
> for 2 years, is a million dollar home (tax appraisal price) with about
> 4500 sq ft and 5 acres, and is being offered at $599k now.  I'm told
> they'd accept under $500k.  Neighbors are wonderful, too.
> 

That sure sounds mouth-watering. But my wife likes places where there is 
no winter (and now ours get colder every year ...) and I'd have a wee 
problem with the property tax rates up there. 2% or more is IMHO 
confiscatory. Oh, and I like proposition 13 (prop tax increase cap) in 
California because I do not trust politicians enough to toss them the 
keys to my bank account.


> 3' of fantastic soils, 45" of rain a year nice and evenly distributed
> all year 'round in a constant drizzle, and everything grows where you
> throw the seed, no digging needed.  What could be better?  ;)
> 

Ah, you shouldn't have written "drizzle", my wife would hate that kind 
of weather.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Frank Buss wrote:
> Jonathan Kirwan wrote:
> 
> [...]
>> 3' of fantastic soils, 45" of rain a year nice and evenly distributed
>> all year 'round in a constant drizzle, and everything grows where you
>> throw the seed, no digging needed.  What could be better?  ;)
> 
> Sounds great if you want to become a farmer :-) I'm living near Cologne
> centre, but a quiet back road near the Rhein. Just a rented flat and not
> acres of grass and bushes around it, but supermarkets, stores, pubs,
> restaurants, theaters, cinemas, parks etc., all within walking distance.
> 

I sure miss those pubs in Cologne. We lived about 20 miles from there. A 
hop onto a train and 30 minutes later you were at Cologne Central. Then 
  a stroll of a few minutes and you could have a nice cold Koelsch beer.

Hint for tourists going there: If you think you master German well 
enough and then discover that you can't understand a thing of what 
people in a Cologne pub are saying, that's normal. I didn't understand 
most of them either.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Frank Buss wrote:
> Joerg wrote:
> 
>> One could add some code so it re-flashes itself once in a while, that's 
>> another option here. However, the device cannot lose power during that 
>> brief period or it'll be really toast. So that would require large 
>> enough electrolytics and some pre-regulator voltage monitoring. The 
>> latter would require a relayout, bigger ECO and all that. Not a VP of 
>> Engineering's favorite path, usually.
> 
> If the flash is big enough, you could copy the program to an unused memory
> area and back again the next cycle. Then the only critial moment is writing
> the switchover. But should be no problem, if you can monitor the supply
> voltage and if you can guarantee, that it remains over the flash limit for
> the time needed to write the switchover bytes.
> 

That's one of the methods I am thinking about. It would require a uC 
with at least twice the flash size but heck, that would be pretty cheap 
insurance. The switchover could be handled by a flag that will not get 
asserted before the whole transfer is complete. Only afterwards would 
the flag for the "old" flash area be disasserted.

The flag is the problem. Unfortunately uC manufacturers have not put 
that much thought into the reset routine. It just jumps to a fixed 
address and when the data there is corrupt the application is toast.


> What do you think of MRAM for critial applications? It's a bit expensive,
> but they claim data retention of minimum 20 years and unlimited number of
> writes. It is even used in a satellite:
> 
> http://www.eetimes.com/showArticle.jhtml?articleID=206900226
> http://www.freescale.com/files/microcontrollers/doc/data_sheet/MR2A16A.pdf
> 

We already have another kind of memory in one application because of 
flash corruption. However, then the question arises: Why have flash in 
the first place?

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

TheM wrote:
> "Jamie" <j...@charter.net> wrote in message
news:S3E4k.66$0...@newsfe05.lga...
>> Joerg wrote:
>>> What do you mean by strong? VHF radio close by? Cell phone? If yes, do you remember how close?
>>>
>>  100 W VHF transmitter ~ 6 feet away.
> 
> I would guess the part went haywire and started overwriting the flash
> itself by some randomly executed code.  Possibly the fuses were not set or
> were even ignored.
> 

Yeah but that would not be cool. 100W at 6ft isn't that much. Many 
applications must live in plastic boxes and there is always a chance 
someone with a 5W contractor radio stands right next to them. Or someone 
fires up a cell phone and the GSM ones can be particularly nasty here.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Jim Granville wrote:
> Joerg wrote:
> 
> <snip>
>>
>> I wish the MSP430 was available in automotive but it ain't. At least 
>> not according to the TI rep.
> 
> For more critical uses, Infineon seem to have well-spec'd uC -
> their new ones all have Error Correcting Flash, and 125'C models.
> 
> http://www.infineon.com/XC800
> 
> Also recently added are a series of Transmitter ICs for Wireless 
> Control, that have Sub 1GHz Transmitters, and Low power Flash C51's
> - one targets Tire Pressure, at Automotive temp range.
> http://www.infineon.com/cms/en/product/promopages/pma5110/index.html
> 

Aha! Thanks. Seems there is some hope. Although I am not much of an 
Infineon fan. The reaction time of their CA office can be, well, just 
like the name suggests, infinity.

> 
> Flash retention is one of those 'fingers crossed' specs from most
> suppliers. They cannot TEST years of use, so they do a little 
> extrapolation, and we all know, extrapolation is dangerous :)
> 

Yes, like global warming :-)

Hold the tomatoes ...

> 
>> One could add some code so it re-flashes itself once in a while, 
>> that's another option here. 
> 
>  From What ?
> 

Copy sectors 1-10 consecutively into RAM, write them to sectors 11-20, 
assert start location 11, disassert start location 1. A month later the 
other way around. And so on. Just like rotating a wood pile so it dries 
evenly.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

James Arthur wrote:
> Joerg wrote:
>> Tim Wescott wrote:
>>> Joerg wrote:
>>>> Tim Wescott wrote:
>>>>> Joerg wrote:
>>>>>> Hello All,
>>>>>>
>>>>>> After some problems a client saw I was treated to my own dose of 
>>>>>> what is likely flash loss: The uC in our mailbox door has become 
>>>>>> erratic. I installed it about three months ago and half of the day 
>>>>>> it receives a good pelting from the sun. First it began not 
>>>>>> recognizing some keys, then it started doing weird stuff like lock 
>>>>>> cycling. Things it wasn't meant to ever do. Batteries, contacts 
>>>>>> and such look ok, reset didn't help, so that's not it.
>>>>>>
>>>>>> TI has an app note about the topic:
>>>>>> http://focus.ti.com/lit/an/slaa392/slaa392.pdf
>>>>>>
>>>>>> Figure 1 looks scary above the 80C range. Later they presented 
>>>>>> another test with a different bake cycle which makes things look 
>>>>>> better but who knows.
>>>>>>
>>>>>> What is you experience with respect to flash errors on uC that are 
>>>>>> exposed to elevated temperatures as most outdoors applications are?
>>>>>>
>>>>> One of my clients makes products that regularly go above 80C, and 
>>>>> that has never been an issue to my knowledge (all the service guys 
>>>>> I used to hang with have either left or been promoted, so I don't 
>>>>> have that immediate knowledge one gets by being service's life 
>>>>> line).  Certainly the to-do if it were recognized would have 
>>>>> bubbled down to me.
>>>>>
>>>>
>>>> Well, in my case it kind of has bubbled down to me now ;-)
>>>>
>>>>
>>>>> OTOH, all the parts are very carefully selected to work over the 
>>>>> industrial temperature range; if your mailbox thingie is designed 
>>>>> with commercial temp range parts all bets are off (and it may be 
>>>>> something else that's happening, too).
>>>>>
>>>>
>>>> It's not just this mailbox but also some MSP430 apps at a client. 
>>>> They predate my involvement there and we are pretty much stuck with 
>>>> that for a while. We are seeing a distinct pattern where those 
>>>> inside smaller boxes fail more often than those in larger and more 
>>>> airy enclosures. This stuff is used in the south where summers are 
>>>> quite toasty.
>>>>
>>> Have you tried cooking them on purpose?  Even if you don't have a 
>>> "real" environmental chamber, you can do a lot with an insulated box 
>>> and a heat gun (including catching the lab on fire (ask me how I 
>>> know!), but that usually entertains the technicians).
>>>
>>
>> That I haven't tried yet. A friend of mine (chemical engineer) did 
>> something similar. After an extended hospital stay he casually 
>> mentioned that his lab was now a black hole and that the door was gone.
>>
>>
>>> I'd toss some in an oven for an extended high-temperature test, to 
>>> see where they failed.
>>>
>>> I'd also check the heat rise against ambient in both small and large 
>>> enclosures.
>>>
>>
>> That's what I suggested to the client, to place some USB temp loggers 
>> in there.
>>
>>
>>> If they get any solar load, I'd throw up my hands and call a 
>>> mechanical engineer who's good with thermodynamics, but that's just 
>>> because I (usually) know where my competence ends.
>>>
>>> Some of the flash parts that I have seen used to success have been 
>>> from TI, but they aren't TMS430s, and they _are_ industrial 
>>> temperature range parts.
>>>
>>
>> I wish the MSP430 was available in automotive but it ain't. At least 
>> not according to the TI rep.
>>
>> One could add some code so it re-flashes itself once in a while, 
>> that's another option here.
> 
> I was going to suggest that.  But, you ask, "How often?"
> 
> A few wild troubleshooting ideas:
> 
> One thing you might do is vary the device's Vdd while reading it, thus 
> changing the read threshold and alerting you to marginal cells before 
> they fail.
> 
> With a heat gun and a device reader you might actually document the 
> bleed-down of the device's memory cells vs: temperature & derive a 
> definitive lifetime projection.
> 
> Another idea: can you control the programming timing?  If so, you could 
> weakly program a test pattern + CRC in the part.  The part could then 
> test the area itself, detecting impending failures.
> 

Sure but that data won't help much. Next month's batch can be all 
different. One could just do the sector swaps often enough, maybe once a 
week. The max number of write cycles is very high these days, well in 
excess of 10000 times. AFAIK that number even goes up with temperature.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Paul Keinanen wrote:
> On Fri, 13 Jun 2008 16:58:25 -0700, Joerg
> <n...@removethispacbell.net> wrote:
> 
>> One could add some code so it re-flashes itself once in a while, that's 
>> another option here. However, the device cannot lose power during that 
>> brief period or it'll be really toast. So that would require large 
>> enough electrolytics and some pre-regulator voltage monitoring. The 
>> latter would require a relayout, bigger ECO and all that. Not a VP of 
>> Engineering's favorite path, usually.
> 
> In a high radiation environment usually some ECC bits are stored in
> each sector and with frequent sector reads you can detect if there are
> flipped bits, correct the errors using the ECC and write back the
> sector.
> 
> In this way, you know when to do the writeback and you can minimize
> the (limited) number of reflashing for a specific sector on the flash.
> 
> I assume this would also work with the data retention time problem at
> elevated temperatures.
> 
> For a program written in assembly, it should not be a problem to
> allocate a number of bytes for the ECC bits at the end of sector and
> use a branch instruction to skip them, but this might be an issue, if
> an HLL is used.
> 

That's an option as well. Although it won't help with power failure 
duyring re-writes.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.