Re: Flash retention in uC at higher temps, experience?

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 do***ent 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.