Flash retention in uC at higher temps, experience?

remember how close?

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

it practically means

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

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

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.

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

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.

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.

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?

remember how close?

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.

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.

Yes, like global warming :-)

Hold the tomatoes ...

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.

On a sunny day (Sat, 14 Jun 2008 09:03:11 -0700) it happened Joerg wrote in :

Why not do a checksum or CRC or hash at startup of code area 1 (assuming 2 code areas with the same code), if the hash is OK then jump to code1, else check area 2 and if that is OK jump to code area2. If one code area fails copy the other one over it and check again. If both fail the check, detonate a smoke bomb or something so people notice there is a problem. Run the check from a timer every now and again, or even from the watchdog if it hangs.

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.

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

Sure. Unfortunately most uC jump to a fixed address at startup and when that area is corrupt it's all gone :-(

On a sunny day (Sat, 14 Jun 2008 09:16:23 -0700) it happened Joerg wrote in :

Would the watchdog interrupt entry point be the same as the code start point?

If not that would be defined, you guessed it, via a flash location :-)

On a sunny day (Sat, 14 Jun 2008 09:49:07 -0700) it happened Joerg wrote in :

Sure, everything is. Then perhaps you should use 3 the same micros (connected) and arbitrage logic.

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

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 ..

sed in

re in

ides

or

itical

True, if something gets us down to

Or a mask version but those are vanishing.