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

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

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

On Sat, 14 Jun 2008 10:20:52 +0200, Frank Buss <f...@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

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=A0pm, 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?
>
> =A0 Our boxes never see direct sun exposure on the semis, but they're enca=
sed in
> an aluminium box, then in a black plastic 'pelican' waterproof case. =A0He=
re in
> Australia, it gets quite warmish over summer, and we routinely see the ins=
ides
> at 50C (122F) or more (as far as the measurement of the internal temp sens=
or
> goes anyway).
>
> =A0 Our flash chips are quite ancient, and although they don't hold any cr=
itical
> information, it's critical enough that you're going to notice if it chucks=
 a
> wobbly.
>
> =A0 Although we get some with corrupt flash data, it's relatively rare.
> --
> Linux Registered User # 302622
> <http://counter.li.org>;

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

Paul Keinanen wrote:
> On Sat, 14 Jun 2008 10:20:52 +0200, Frank Buss <f...@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.

"Joerg" <n...@removethispacbell.net> wrote in message
news:i0S4k.1439$L...@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.

M 

"Frank Buss" <f...@frank-buss.de> wrote in message news:i...@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.

I love mram, however these things are sensitive to magnetic field, right?
Still not exactly bullet proof.

M

On Fri, 13 Jun 2008 16:31:00 -0700, Joerg
<n...@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

In article <pCV4k.14650$H...@news.siol.net>, TheM says...
> "Frank Buss" <f...@frank-buss.de> wrote in message news:i...@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 **

legg wrote:
> On Fri, 13 Jun 2008 16:31:00 -0700, Joerg
> <n...@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.