Flash retention in uC at higher temps, experience?

[Joerg]

Jonathan Kirwan wrote:

On Fri, 13 Jun 2008 16:23:42 -0700, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Jonathan Kirwan wrote:
On Fri, 13 Jun 2008 15:42:27 -0700, Joerg
notthisjoergsch@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.

 

[Joerg]

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.

 

[Joerg]

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.

 

[Joerg]

TheM wrote:

"Jamie" <jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote in message news:S3E4k.66$0J4.2@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.

 

[Joerg]

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.

 

[Joerg]

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.

 

[Joerg]

Paul Keinanen wrote:

On Fri, 13 Jun 2008 16:58:25 -0700, Joerg
notthisjoergsch@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.

 

[Paul Keinanen]

On Sat, 14 Jun 2008 09:14:57 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Paul Keinanen wrote:
On Fri, 13 Jun 2008 16:58:25 -0700, Joerg
notthisjoergsch@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.

With sector specific ECC, you reduce the likelihood for sector
specific reflashing and also reduce the time of reflash (full
reflash/sector specific reflash).

If this kind of reducing the likelihood for a complete failure is not
sufficient e.g. large capacitors for data retention, you have to go
for a doubly/triple redundant system to avoid such problems.

Paul

 

[Paul Keinanen]

On Sat, 14 Jun 2008 10:20:52 +0200, Frank Buss <fb@frank-buss.de>
wrote:

Paul Keinanen wrote:

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.

You can collect all ECC bits at the end of the flash.

This is a good idea as long as you do not perform these updates too
often, overflowing the maximum flash write count for a specific
cell/sector.

Paul

 

[Joerg]

Paul Keinanen wrote:

On Sat, 14 Jun 2008 09:14:57 -0700, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Paul Keinanen wrote:
On Fri, 13 Jun 2008 16:58:25 -0700, Joerg
notthisjoergsch@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.

With sector specific ECC, you reduce the likelihood for sector
specific reflashing and also reduce the time of reflash (full
reflash/sector specific reflash).

If this kind of reducing the likelihood for a complete failure is not
sufficient e.g. large capacitors for data retention, you have to go
for a doubly/triple redundant system to avoid such problems.

True, if something gets us down to <<10% of failure that is in many
cases sufficient. Not in medical or aeronautics though.

--
Regards, Joerg

http://www.analogconsultants.com/

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

 

[Joerg]

Paul Keinanen wrote:

On Sat, 14 Jun 2008 10:20:52 +0200, Frank Buss <fb@frank-buss.de
wrote:

Paul Keinanen wrote:

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.
You can collect all ECC bits at the end of the flash.

This is a good idea as long as you do not perform these updates too
often, overflowing the maximum flash write count for a specific
cell/sector.

It's >10000 times on most modern device, per datasheet. In reality more
like 100000 times. So even if you do it once a week there will still be
archeologists wondering what the heck these ancient folks had done.

--
Regards, Joerg

http://www.analogconsultants.com/

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

 

[ThanderMaX]

The black container will absorb more heat than the white one. (gen
Physics )
Try wrapping the container with shiny tape , see the result ..


On Jun 13, 4:14 pm, John Tserkezis
<j...@techniciansyndrome.org.invalid> wrote:

Joerg wrote:
What is you experience with respect to flash errors on uC that are
exposed to elevated temperatures as most outdoors applications are?

  Our boxes never see direct sun exposure on the semis, but they're encased in
an aluminium box, then in a black plastic 'pelican' waterproof case.  Here in
Australia, it gets quite warmish over summer, and we routinely see the insides
at 50C (122F) or more (as far as the measurement of the internal temp sensor
goes anyway).

  Our flash chips are quite ancient, and although they don't hold any critical
information, it's critical enough that you're going to notice if it chucks a
wobbly.

  Although we get some with corrupt flash data, it's relatively rare.
--
Linux Registered User # 302622
http://counter.li.org

 

[legg]

On Fri, 13 Jun 2008 16:31:00 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Tim Wescott wrote:


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.

I suggest you paint your box or faceplate a different color.

Your aim should be to avoid producing temperatures that are not
neccessary in direct sunlight.

RL

 

[Robert Adsett]

In article <pCV4k.14650$HS3.713709@news.siol.net>, TheM says...

"Frank Buss" <fb@frank-buss.de> wrote in message news:i5s7vw2ybqby.17ppigai6cf64.dlg@40tude.net...
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

Wow, looks like they are making progress. The last unit I used was 64K serial (I2C) from Ramtron
and it was limited to 10^12 read/write cycles which came out as years at max I2C bus speed.

First the Ramtron devices are FeRam not MRAM.

Second Ramtron has also been claiming unlimited writes for some time
now. IIRC the limit was a function of axygen contamination. Apparently
they solved that problem.

Robert
** Posted from http://www.teranews.com **

 

[Joerg]

legg wrote:

On Fri, 13 Jun 2008 16:31:00 -0700, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Tim Wescott wrote:

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.

I suggest you paint your box or faceplate a different color.

Your aim should be to avoid producing temperatures that are not
neccessary in direct sunlight.

Not so easy on an existing product. But from experience it seems the
temps weren't all that different between a black box and an off-white
one. Maybe the off-white one crept up a little slower.

--
Regards, Joerg

http://www.analogconsultants.com/

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

 

[Jonathan Kirwan]

On Sat, 14 Jun 2008 08:36:57 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Jonathan Kirwan wrote:
On Fri, 13 Jun 2008 16:23:42 -0700, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Jonathan Kirwan wrote:
On Fri, 13 Jun 2008 15:42:27 -0700, Joerg
notthisjoergsch@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."

Yes, I did. I gather you want to do that.

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.

My place is appraised at $850k (down there, I know that is just a
shack but up here it's 5000 sq ft of quality, showy home and lots of
acres of prime hilltop land) and my property taxes are $4400/year.
Which is kind of high, I admit. It's the income taxes you'll probably
hate. It's a graduated rate, but I think the top rate (which applies
to most engineers, without even asking) is 9%. However, no sales tax.

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.

I did that on purpose. I didn't want to make it seem too inviting.
Actually, I've come to appreciate the constant press of low clouds
overhead and the slippery feel of moist moss as you carefully walk
across your one year old, rotting wooden deck.

Jon

 

[Jim Granville]

Joerg wrote:

Jim Granville wrote:

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

and they also have a 140'C rated variant....

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.

They do seem to be expanding use of Digikey.

Digikey shows 4,153 Infineon items, of which 275 are Microcontrollers,
and of those 46 are XC8xx series.

[Just not yet the nice looking 20 pin XC864, or 64K XC878's, or
the Wireless Control ones above ..... too new... - sigh...]

-jg

 

[Jonathan Kirwan]

On Sat, 14 Jun 2008 09:40:25 +0200, Frank Buss <fb@frank-buss.de>
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

Our family grows/raises most of the food we consume. It's nice
knowing where it all comes from and how it was treated and prepared.

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 don't have all that within walking distance. It's a 5 minute drive
to the nearest hospital, for example, and 20 minutes drive to an
international airport (PDX.) But we do have a grocery store (not a
supermarket), a pub, a restaurant or two, and many, many parks all
within easy walking distance of home.

Okay. I'm having fun. I hope you don't mind if I post a few links to
pictures.

These pictures are from my own land, showing paths that proceed from
my home into the wooded parts of my property:

http://www.infinitefactors.org/misc/images/Home%20Trails.jpg
http://www.infinitefactors.org/misc/images/Home%20Trails%202.jpg

That will give you a flavor for the flora.

Mt. Hood rises up from sea level to about 11,300' and is about 15
miles from my home. Here is how it looks from a lake that is very
close to my home (in the summer):

http://www.infinitefactors.org/misc/images/Mt%20Hood.jpg

This water fall (among literally more than a hundred within a short
distance) is about a 15 minute drive from home.. over 600 feet:

http://www.infinitefactors.org/misc/images/Multnomah%20Falls.jpg

The Columbia River flows by Mt. Hood's northern base. This viewpoint
is actually closer to my home than the above falls -- about a 10
minute drive:

http://www.infinitefactors.org/misc/images/Crown%20Pt.jpg

All of the above is in relatively easy bicycling distance.

In Oregon, it is illegal to own or fence or otherwise control coastal
land. Some 400 miles of coastline is public land. The only state of
the USA that does this, I think. In any case, here is one photo of
what our coast partly looks like:

http://www.infinitefactors.org/misc/images/Boardman.jpg

Jon

 

[Jim Granville]

TheM wrote:

"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:i0S4k.1439$LG4.82@nlpi065.nbdc.sbc.com...

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.


It could be a design with long supply wires (as antennas) and poor RF
blocking caps close to uCPU.

Flash corruption due to EM field at 6 feet distance sounds a bit far fetched.

It will not be a Direct Flash Cell effect, but more likely a Software
crash, that jumps into a Flash Write routine.

This is one reason why many Automotive designs insist on a FLASH_ENABLE
pin, so that a simple SW crash CANNOT cause un-recoverable damage.

We have some designs that will NOT use IAP Flash controllers, for
exactly the same reason.

Adding IAP is a convenient feature, but it also can be a point of weakness.

-jg

 

[Jim Granville]

Robert Adsett wrote:

In article <pCV4k.14650$HS3.713709@news.siol.net>, TheM says...

First the Ramtron devices are FeRam not MRAM.

Second Ramtron has also been claiming unlimited writes for some time
now. IIRC the limit was a function of axygen contamination. Apparently
they solved that problem.

Not quite:
The latest Mar 2008 data for the FM25H20 2MBit FRAM, (40MHz) specs 10^14
Wd/Wr,
(which I guess is per Byte?).

Most data application will be well under that, but it could start to
bother an execute-from-flash design, sitting in a tight loop.

These parts have very Niche-prices, around 20x that of vanilla flash,
so you really have to need their better features

-jg