MKL04 Flash lifespan? Can a Teensy be made to last decades?

Status
Not open for further replies.
P

Peter S

New member
Dear Paul Stoffregen,

I'm designing a modular automation system for use in our line of modular buildings and I'm using the Teensy as the core for all the I/O nodes because of the ease of development, and the ability to utilize the Arduino IDE for future customization. Presently there are 20 I/O node designs in our system. Our design lifetime for these buildings is 100 years and thus I have placed great emphasis on longevity. As Flash memory forgets over time, lifespan of the firmware is of primary concern.

My question is whether there is any mechanism available, or whether one could be made available to reflash both the MKL04/02 and the connected ARM using the data already present in the flash of each chip? I understand interrupting this process would likely result in bricking but I also see the hardware outlasting the flash contents based on the Freescale flash longevity data I've seen. Running a command once a decade to refresh the Flash would allow us to specify the automation components' life using the component parts' MTBF rather than the far more nebulous Flash retention time.

We are presently working on a contract for 4,000 specialized modular buildings which in the present configuration would necessitate the use of several 10s of thousands of Teensys. Clearly we would need this feature to be able to be launched via software (all nodes are on CAN) as physically attaching to each embedded board would be an impractical saga. Some kind of a relatively impossible unlock sequence, perhaps one timed by the MKL04/02 taking hours or more, would be ideal.

Thank you for your consideration,
-Peter S
 
Flash has a data retention time of 100 to 150 years at temperatures of 25°C-20°C. Not sure which Freescale documents you are referring to, because the ones I've seen indicate even longer retention times. It's important you look up the retention time, not the durability because that also takes regular reflashing of the memory into account.
 
Epyon, it's odd that you would use a random, unrelated TI document to make reply about a Freescale chip which is built with different geometries, different fabrication processes, and in a different fab. http://www.mouser.com/ds/2/302/K20P64M72SF1-1126422.pdf is the datasheet for one of the CPUs supported by the Teensy and you can clearly see in section 6.4.1.4 Reliability specifications, Table 22. NVM reliability specifications, that the program flash is good for 20 years at 20-25C according to parameter tnvmretp1k. During the day many of my nodes will be exposed to 35, 45, and up to 60 degrees celsius where flash has a lower retention time, however that retention time is not characterized by temperature in the datasheet and retention is simply extrapolated and guessed at for a general example. Freescale Engineering Bulletin EB618 http://cache.freescale.com/files/microcontrollers/doc/eng_bulletin/EB618.pdf from 2005(!) which is referenced in the 2012 NXP K20 ARM datasheet shows flash retension reduced to 15 years at elevated temperature. 15 years is not terribly acceptable as a lifespan for our automation components, especially when a refresh of the flash every five to ten years would eliminate the issue entirely.
 
That table is exactly the table I wanted to avoid, because the numbers there are after 1k and 10k full program/erase cycles. For a Teensy that will be programmed once and then left running these numbers are meaningless.

The flash technology used by different manufacturers is actually all quite similar. I used the TI document because it gives some more info about the testing process. If you want Freescale NVM numbers you can check a similar document here, that indicates retention times over 100yrs for all their memory types.
 
Epyon, I'm making a commercial inquiry of Mr. Stoffregen and I'm not particularly interested in your armchair analysis. Did you even notice you linked to the exact same EB618 that I did? The K20 datasheet lists 20 years at 20-25C with no additional qualification. I gave you the exact reference. You don't seem to understand that product designers need to use minimum values, not extrapolated "typical" values. There are well over 150,000 devices of my design in use in the marketplace containing embedded CPUs. I take my craft very seriously because reliability depends on it.
 
Peter S said:
when a refresh of the flash every five to ten years would eliminate the issue entirely.
Click to expand...

These chips, and most modern microcontrollers from every silicon vendor, have more non-volatile memory than only the program space. While the details are highly secret, it's well known that most vendor implement extra flash memory and store a non-volatile provisioning table. Allowing a small number of "bad blocks" of flash allows for greatly improved yields, since a good portion of the entire die is the memory. Some chips even do the same for RAM.

It's also no big secret that many similar parts are actually the same physical silicon, with non-volatile config bits to customize which features you get. This too can be used for improving yield, but whether they actually do so is a good question. But the setup costs for masks and manufacturing runs are enormous, so just reducing the number of physically different dies (even when some are larger that needed for the disabled features) results in massive costs savings for semiconductor manufacturers,

Obviously you can't reprogram these highly secret / proprietary non-volatile configuration bits.
 
Thank you for your reply.

The prospect of a provisioning table and die customization bits is interesting indeed. I will contact the design group at Freescale to see if they are willing to divulge what the state of affairs is here. If there are no die level hurdles, would you be willing to discuss a self-reflash/mutual reflash feature? It could lead to the sale of as many as 76,000 of your MKL04 parts for the contract I mentioned in my initial post. Hopefully that would be just the beginning.

When I found your work it seemed like a natural fit and access to the Arduino IDE is more than highly desirable for us. Before finding the Teensy I had actually planned on using a pair of MCUs with each controlling the other's SWD port for reprogramming to obtain the longevity of a masked ROM part. The expense is easily warranted by the additional specifiable product lifespan and RTC resources will be available for accurately judging when a refresh is necessary. All these chips will be on battery backed power so I see this as being as simple as a subroutine executed on each ARM in succession to perform the necessary reads and immediate write-backs over SWD, however it also requires both chips to be unprotected. If self-write is supported in the KL0x devices, for code security I could also see the KL04 self-refreshing it's own data from within while the K-series device refreshes the KL04's configuration bits using SWD. I've got no issue dedicating any additional pins necessary to the process and in my rough sketches, reset is generated via external logic so the two chips can watchdog each other if desired. Ideally we could discuss a license for us to load your code during manufacture via a test jig so that we could build with blank parts, especially since we're talking about a custom feature here.

Previous to this position I worked in a 50K sq.ft. facility with 12 SMT lines that cranked out massive numbers of SSDs every day and there I was exposed to a great deal of cutting edge and present use flash technology. In my experience from manufacturer data and die examination, configuration cells are typically much larger and insulated much better than the minimum-size cells in the memory arrays. It's also not uncommon to have configuration data arrays implemented with larger geometry cells featuring greater longevity but much lower endurance. I can say for certain from data obtained under NDA that this is the case with some NAND flash used in SSDs for the "extra" block provisioning data so I have great hope that configuration bits are not a hurdle.

The flash data array error rates are so high nowadays in the highest density NAND parts that your data exists intact only by virtue of the ECC logic. We've hit the point where there just aren't enough atoms left to store the charge and the smallest defects greatly affect retention time. The super density MLC flash used in server cache SSDs these days can have a retention as low as 3 months, however they're constantly being refreshed using wear leveling from spinning disks so 3 months isn't an issue.

Thanks again,
-Peter S
 
Status
Not open for further replies.
Back
Top