Flash retention in uC at higher temps, experience?
Joerg
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?
--
Regards, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Jonathan Kirwan
<notthis...@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.
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. ;)
Jon
John Tserkezis
> 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>
Tim Wescott
> 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?
>
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.
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).
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
Joerg
> On Fri, 13 Jun 2008 15:42:27 -0700, Joerg
> <notthis...@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 :-(
> 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.
Joerg
> 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).
>
50C is easy, we even get that as an ambient temperature around here. But
in summer stuff inside of enclosures can easily reach 80C or more. Worst
case for 10h/day all summer.
> 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.
Chucks a wobbly, cool. Learned a new expression!
>
> Although we get some with corrupt flash data, it's relatively rare.
Depends on what "relatively rare" means ;-)
Joerg
> 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.
Tim Wescott
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).
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.
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.
Jamie
I have found strong R.F. and EMF's in close proximity have caused the
flash to get corrupted in PIC's. I'm sure it effects others.
Joerg
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. 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.
Joerg
What do you mean by strong? VHF radio close by? Cell phone? If yes, do
you remember how close?
Jamie
Another problem I have heard of but never experienced and
that is police microwave radar. I guess for some uC's there
are circuit paths that match the wave length and can cause
unwanted effects in the memory.
--
http://webpages.charter.net/jamie_5"
Jim Granville
<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.
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
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 :)
> One could add some code so it re-flashes itself once in a while, that's
> another option here.
From What ?
-jg
James Arthur
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.
Cheers,
James Arthur
Jonathan Kirwan
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.
>> 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.
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? ;)
Jon
Paul Keinanen
<notthis...@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.
Paul
Frank Buss
[...]
> 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.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss
> 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.
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
Frank Buss
> 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.
John Tserkezis
> 50C is easy, we even get that as an ambient temperature around here. But
> in summer stuff inside of enclosures can easily reach 80C or more. Worst
> case for 10h/day all summer.
For us, it was a non-issue above 40C, because we didn't rate the measurement
electronics to be within specification above that point. We actually could
have gone higher, but the built-in LCD 1x16 display wasn't rated above 40. It
was a nice round number so we left it at that.
>> 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.
> Chucks a wobbly, cool. Learned a new expression!
It's an oldish Australian term. I don't know how wide spread it is, but
everyone here who I've mentioned it to knows what it implies.
>> Although we get some with corrupt flash data, it's relatively rare.
> Depends on what "relatively rare" means ;-)
Of the dozen or so broken boxes I used to see every week, we'd get one with
trashed flash data every month or so.
I have no idea how many boxes were in service in the outside world. I'm
guessing many hundreds, but I really have no idea as I was only involved in
the service side, not sales or other areas that would give me an idea of what
was already sold.
TheM
> 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
TheM
> 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
Frank Buss
> 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
Joerg
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.
Joerg
> 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.
Joerg
> 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?
Joerg
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.
Joerg
> 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.
Joerg
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.
Joerg
That's an option as well. Although it won't help with power failure
duyring re-writes.
Paul Keinanen
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
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
ThanderMaX
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.
Joerg
True, if something gets us down to <<10% of failure that is in many
cases sufficient. Not in medical or aeronautics though.
Joerg
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.
TheM
> 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.
M
TheM
> 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.
I love mram, however these things are sensitive to magnetic field, right?
Still not exactly bullet proof.
M
legg
<notthis...@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
> "Frank Buss" <f...@frank-buss.de> wrote in message news:i5s7vw2ybqby.17...@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
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.
Jonathan Kirwan
<notthis...@removethispacbell.net> wrote:
Yes, I did. I gather you want to do that.
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
Jonathan Kirwan
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
> 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
Jim Granville
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
> In article <pCV4k.14650$HS3.7...@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
Gordon S. Hlavenka
> 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.
I'm working with an 89lpc952 (Phillips/NXT) which comes preprogrammed
with a bootloader in the top Flash sector. There's a flag that, when
set, will cause execution to start there instead of the normal reset vector.
You're free to overwrite the bootloader with something else, so perhaps
that facility could be used for one side of the flipflop?
Of course, the '952 also has IAP which I don't think can be disabled...
--
Gordon S. Hlavenka http://www.crashelectronics.com
Vote Ron Paul in 2008! Call 866-737-5066
Robert Adsett
> Robert Adsett wrote:
>
> > In article <pCV4k.14650$HS3.7...@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?).
Interesting. Their lower density parts like FM25L512 quote unlimited
read/write cycles. Maybe endurance issues have arisen again at finer
geometries?
> 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 :)
For small sizes the price premium over EE is small. I use them for the
security of a faster write (the memory is vulnerable for a smaller
window).
Everett M. Greene
> 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? ;)
>
> 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.
And it's well known that (western) Oregonians don't tan,
they rust.
legg
<notthis...@removethispacbell.net> wrote:
>legg wrote:
>> On Fri, 13 Jun 2008 16:31:00 -0700, Joerg
>> <notthis...@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.
With all other variables constant, a reduced rate of rise means a
lower end-point of thermal burden. Light colours are preferable where
reflective surfaces are not possible.
Changing the material, or material grade to something that is not
clear/opaque to infrared can also have an effect. A paint overcoat
rather than internal pigment (~of plastic). Adding irregular surface
finish or stippling/ridging may also have a beneficial effect.
Failing that, a sacrificial face-plate on the most exposed surfaces,
decoupled physically from the case itself.
RL
Jonathan Kirwan
;)
I just spent a nice day today at a fly-in for nitro and electric
helicopter models. It was a nice day of about 64-67F and I spent
about 5 hours in the 45-degree N latitude sun. Horrible sunburn I'm
sitting here suffering from, right now! (I get 2nd degree burns in 15
minutes in LA, by the way. I need the cloud cover!)
Jon
Didi
> ....
> Okay. I'm having fun. I hope you don't mind if I post a few links to
> pictures.
>
It does looks terrific and with all the woodpeckers squirrles and
whatnot
it sounds like a paradise for the camera-hunter I have become lately.
But what about winter? How long/harsh is it typically? (Not last
winter,
I guess we are all still expecting it to quite go away in mid
June... :-) ).
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/f1ad55f68483a56a?dmode=source
Hans-Bernhard Bröker
> 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.
Or they insist that flash-write routines simply don't exist in the
application. A routine that's not physically present in the chip can't
accidentally be run. Nice and simple, really.
They only get uploaded into the controller RAM at flash-update time.
TheM
> TheM wrote:
>> 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.
Yep, I thought that was the real cause. I think Joerg pointed out GSM phones
can be especially nasty with their pulsed carrier.
100W VHF at 6-feet away should be relatively easy to counter with proper pcb
layout and ferrite beads and RF blocking caps, but designer probably never expected
strong rf fields. Even worse would be if the write protection fuses were not set.
> 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.
I suspect the programmed fuses that should prevent writing over flash section may
not always work. External pin is probably more reliable.
M
TheM
> Robert Adsett wrote:
> 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
Ok, still two orders of magnitude improvement. The bad part is it applies to
reading as well :(
The 64K I2C parts were 1-2 euro AFAIR. 4M freescale part is another story.
I like them for speed and the fact they can't be destroyed by runaway software,
at least in I2C variant.
M
Joerg
It a similar income tax structure here in CA with the dems wanting more
and more and more. Luckily we now have a 2/3 majority req for tax raise,
thanks to the aforementioned Prop 13. We also have a sales tax on top of
that and it still ain't enough :-(
However, you may just be lucky that you bought your house at low cost.
I've heard people retiring to Oregon and after buying a $400k house they
got socked with an $8k (!) tax bill. Oh no, not me. One really has to
watch it these days.
>>> 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.
>
In winter it's the same here. We are on a hill and often "in" the
clouds. Our Rottweiler used to bark them away upon approach but he gave
up on that. We found PreservaWood deck stain to hold up pretty well.
Joerg
> 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.
>
Do it again but "in stock only". Makes it dwindle down to 1209 parts.
IMHO the guys there need to learn about marketing.
> [Just not yet the nice looking 20 pin XC864, or 64K XC878's, or
> the Wireless Control ones above ..... too new... - sigh...]
>
Try to get samples out of their Bay Area office. Did that for a FET a
while ago. It took about 10 phone calls to get one call back. Told them
I'd pay whatever it takes. Nada, zilch. That taught me a lesson :-(
Joerg
> Joerg wrote:
>> 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.
>
> I'm working with an 89lpc952 (Phillips/NXT) which comes preprogrammed
> with a bootloader in the top Flash sector. There's a flag that, when
> set, will cause execution to start there instead of the normal reset
> vector.
>
That would be a start, as long as the device can still be programmed
after you've chucked the bootloader.
> You're free to overwrite the bootloader with something else, so perhaps
> that facility could be used for one side of the flipflop?
>
> Of course, the '952 also has IAP which I don't think can be disabled...
>
IAP can increase the risk of flash corruption but not being familiar
with the NXP devices I don't know by how much. Nowadays most uC can
write flash from within a application though.
Ian Stirling
> 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
Though not directly related,
http://space.brunel.ac.uk/bitstream/2438/1385/1/JonesKenyon-SIMS-FSI-archive.pdf
is interesting.
(data retention at 450C)
Joerg
That's the Irish/Swedish genes in you I guess. Mine are mostly German
but I don't get sunburn easily, I just become darker and darker. Hmm,
maybe I've got some other genes in me that nobody remembers ...
Jonathan Kirwan
>Jonathan Kirwan wrote:
>> ....
>> Okay. I'm having fun. I hope you don't mind if I post a few links to
>> pictures.
>>
>
>It does looks terrific and with all the woodpeckers squirrles and
>whatnot
>it sounds like a paradise for the camera-hunter I have become lately.
> But what about winter? How long/harsh is it typically?
The climate here is quite moderate, generally. Winters can be like
this in the higher elevations (I'm at about 900' above sea level), but
this is rarer at the lower elevations in western Oregon:
http://www.infinitefactors.org/misc/images/Snow-Bent%20Trees.jpg
That above picture last happened near my property in winter of 2003.
But I've not seen the like since then.
We used to get a silver thaw in the lower elevations near Portland
almost every other year or every year. I haven't seen one since 1981,
though. And Mt. Hood has lost close to 50% of its glacier mass
balance (gleaned from personal discussions with two climate
researchers -- one who studies mass balance of the Washington state
glaciers and the other who personally treks through Mt. Hood every
year gathering surface ice/snow data) in the last 30-50 years. (If I
recall, there are 11 significant glaciers on Mt. Hood.) I have lived
here since 1955 and my own experience concurs with this trend. So the
winters in the lower elevations of the Willamette valley, in my
opinion, have become less severe in terms of ice/snow. However, I
think, precipitation seems to have remained similar overall. Just the
distribution seems to be perhaps a little more rain in the winters and
less in the summers.
In short, you'd find it a paradise for photography pretty much all
year 'round.
>(Not last winter,
>I guess we are all still expecting it to quite go away in mid
>June... :-) ).
Yes, it's been weird here, this year. There seems to have been a
significant change in the wind patterns over the north polar area -- a
shift in the cyclonal center of mass. Winds and water currents drove
sea ice along the edge of the Russian Arctic (Novaya Zemlya) and a
sort of polynya emerged a bit early off the Canadian arctic coast
between the archipelago, the Alaska border and Baffin Bay. This year
seems to be unusual to me in these respects and perhaps may have
played a part in the somewhat unusual (record breaking, here) weather
patterns we've had in the month of May.
By the way, that polynya I mentioned and other smaller polynyas
suggest furthering of the thin and fairly weak annual ice of late.
This is consistent with the fact that the relative fraction of
multi-year ice in the central Arctic has plummeted, roughly since the
mid-1990s. However, it also seems that this year's first year ice
(brine pocketed) is in an unusual location that may help it survive
better than usually expected -- much of it is farther north than usual
so it might be less vulnerable to melt allowing time for the brine to
expel and the ice to firm up somewhat. Still, while having first year
ice further north means that ice may have a better chance to continue
a while longer that shouldn't be read as good news -- it means that
first year ice is forming closer to the pole which is generally not
good big picture news and the overall direction of decline there
continues.
As more of the polar ocean becomes exposed to solar insolation, which
has quite a different albedo, I expect continued significant and
interesting changes in the energy transfer mechanisms for some years.
Jon
Jonathan Kirwan
I might be a bit more of a mutt than I know about, too. But I have
the near transparent skin you'd expect of those needing vitamin D
production in their skins in regions north of the arctic circle. :)
In high school, back when there wasn't an "invisible man" that the
biology class could use, I got trotted up so kids could see all the
veins! Embarrassing. ;)
Jon
Jonathan Kirwan
<notthis...@removethispacbell.net> wrote:
I am glad to hear that some Californians believe that kind of figure!
It might act to slightly stem the otherwise larger flood coming into
the state. I've never seen it and especially never for something
costing $400k, though. And I think I've lived in the most highly
taxed areas of the state so I'd like to know where exactly that
occurs, because it would be an interesting exercise to go check.
>>>> 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.
>
>In winter it's the same here. We are on a hill and often "in" the
>clouds. Our Rottweiler used to bark them away upon approach but he gave
>up on that. We found PreservaWood deck stain to hold up pretty well.
I'm finding myself tearing up the decking (the home is 5000 sq ft, and
the decking is about another 4000 sq ft around it) in sections,
treating the wood, replacing pieces that need replacing, and putting
things back... each and every year, just to keep apace the damage.
Designing any structure here means paying CLOSE attention to water
flows. For example, you dare not install a window into the side of
the house in such a way that you leave a flat "lip" on the topside.
Water will collect on even a quarter-inch protrusion and will quite
simply rot out any wooden siding nearby, including cedar. Slopes are
required everywhere -- no right angles anywhere, not even vertical
ones, when working with wooden structures. Concrete and asphalt is
quickly covered in moss and requires pressure washing on a regular
basis (my quarter mile driveway comes to mind and is requiring yet
another long workout from me, this year.) Life grows on rocks, glass,
and on top of life growing on top of life growing on top of life. I
have ferns growing on my trees, and moss growing on those same trees
AND the ferns growing on them!
Moss grows on your car bumpers and rubber insulation, as well. 20
mule team boraxo, powdered zinc, and powdered iron become your friend,
though. :)
Jon
Joerg
Server not found :-(
Jim Granville
> Jim Granville wrote:
>> 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.
>>
>
> Do it again but "in stock only". Makes it dwindle down to 1209 parts.
> IMHO the guys there need to learn about marketing.
>
>
>> [Just not yet the nice looking 20 pin XC864, or 64K XC878's, or
>> the Wireless Control ones above ..... too new... - sigh...]
>>
>
> Try to get samples out of their Bay Area office. Did that for a FET a
> while ago. It took about 10 phone calls to get one call back. Told them
> I'd pay whatever it takes. Nada, zilch. That taught me a lesson :-(
True, they do need a 'motivated buyer' :)
- and I'll also admit we do not currently have infineon devices in
active production designs
(but we did use their C517 & CAN devices, some years ago, and have
short-listed their MOSFETs recently... )
That said, they must be doing something right, as I see infineon are
now #1 in Industrial :
[13 June 2008 MUNICH, Germany — According to a recent study from market
researcher Semicast (Northampton, UK), Infineon for the first time ranks
number one in the industrial sector, ahead of STMicroelectronics and
Renesas Technology.]
-jg
Ian Stirling
> Ian Stirling wrote:
>> In sci.electronics.design Joerg <notthis...@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
>>
>> Though not directly related,
>> http://space.brunel.ac.uk/bitstream/2438/1385/1/JonesKenyon-SIMS-FSI-archive.pdf
>> is interesting.
>> (data retention at 450C)
>
>
> Server not found :-(
Oops - mispastee.
http://dspace.brunel.ac.uk/bitstream/2438/1385/1/JonesKenyon-SIMS-FSI-archive.pdf
Joerg
I don't trust such sources too much. What I see in my daily biz is that
most circuits contain tons of American semiconductors, some ST because
they often have really low prices, and passives are all over the map and
usually not country-specific.
For jelly-bean parts pricing is everything. Guys like us spec in a
MMBT3904 and then there are 8-10 manufacturers.
AFAIK the earnings at Infineon are still negative. Not exactly my role
model for a successfully run semiconductor manufacturer. And, of course,
one has to ask oneself why other companies such as National earn a
profit. They must be doing something right.
Joerg
> In sci.electronics.design Joerg <notthis...@removethispacbell.net> wrote:
>> Ian Stirling wrote:
>>> In sci.electronics.design Joerg <notthis...@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
>>> Though not directly related,
>>> http://space.brunel.ac.uk/bitstream/2438/1385/1/JonesKenyon-SIMS-FSI-archive.pdf
>>> is interesting.
>>> (data retention at 450C)
>>
>> Server not found :-(
>
> Oops - mispastee.
> http://dspace.brunel.ac.uk/bitstream/2438/1385/1/JonesKenyon-SIMS-FSI-archive.pdf
Interesting, thanks. However, the house fires they mentioned will
usually present a whole different problem. The enclosures of most things
electronic are plastic and will have shriveled into clumps that are
beyond recognition. With lots of other debris on top of them.
Gordon S. Hlavenka
> That would be a start, as long as the device can still be programmed
> after you've chucked the bootloader.
With a programmer you can. Obviously, once the bootloader is gone you
can't program through the '952's onboard serial port.
> IAP can increase the risk of flash corruption but not being familiar
> with the NXP devices I don't know by how much. Nowadays most uC can
> write flash from within a application though.
Well, you'd have to be able to, to reflash-and-switch :-)
Writing to Flash with the IAP facility is a multi-step process so there
is some protection against runaway code.
Joerg
> Joerg wrote:
>> That would be a start, as long as the device can still be programmed
>> after you've chucked the bootloader.
>
> With a programmer you can. Obviously, once the bootloader is gone you
> can't program through the '952's onboard serial port.
>
Or you can write your own little bootloader into your code. That how the
MSP430 guys often do it when they don't like the one from TI.
>> IAP can increase the risk of flash corruption but not being familiar
>> with the NXP devices I don't know by how much. Nowadays most uC can
>> write flash from within a application though.
>
> Well, you'd have to be able to, to reflash-and-switch :-)
>
True :-)
> Writing to Flash with the IAP facility is a multi-step process so there
> is some protection against runaway code.
>
--