FRAM endurance

old_cow_yellow said:

Thus if the FRAM is used to store code and the MCLK is at 16MHz, there may be up to 1.6*10**6 “write cycles” per second

Those reads won't be always the same position. Except if you have a "JMP $" endless loop. Then your 2 years are correct. But this is a rather unlikely code. And it is worst-case. Even if a bit fails after 2 years in this endless-loop szenario, then there's the ECC that keeps it running for some more time.

The more critical thing is using the FRAM as stack area per default linker setting. This is slow (waitstates) and wears the FRAM unnecessarily with 'real' writes. There is RAM on these devices, it should be enough for the stack.

However, not all FRAM technologies are destructive on read. 1T1C or 2T2C cells are, 1T cells aren't. 1T cells use a field effect transistor where the gate insulation was replaced by a ferroelectical material. It is programmed by a gate-source voltage and keeps its state when you read it by applying a source-drain voltage.

This is similar to the FLASH 'floating gate' field effect transistor, Just that the gate is not 'charged' but 'magnetized'.

But right now reading an article from TI about their FRAM, it looks like they use a destructive reading.

But you can turn the case upside down: copy your code from FRAM to RAM after reset and let it run there. FRAM keeps non-volatile data and init code and init values. SRAM contains the code that is heavily executed.
This will also speed up code execution for frequencies above 8MHz (no waitstates on SRAM).

OCY, Jens-Michael,

This is actually a common question.  We are coming out with some documentation on this, but we have theorized the endurance all the way up to 2E15 endurance cycles.  Even given the worst case, very unlikely scenario described above, this would still take over 20 years to run through endurance.

In addition, we have NEVER seen a piece of memory fail in testing.  This is a conservative theoretical limit.

Finally, these endurance characteristics only apply for a "same-state" write (most commonly a refresh/read operation).  If you write a different value into the memory again, then the endurance starts over again like it was never written to.  In other words, using the memory RAM gives you unlimited write endurance.

It's strange how even quoting such an astronomical number as 10^14 still caused people to pull out their calculators and work out some rough math.  It's also great when most of those calculators are made by us :).

 

 

jborgeson said:

In addition, we have NEVER seen a piece of memory fail in testing.

Well, that's no point.
I doubt that there has been any piece in test now for so many years, as the technology itself isn't that old.

It is similar to the MTBF of devices which is given despite the fact that there is no device that has even reached the MTBF.
Usually, this is calculated by a formula that assumes an increased ageing through an increased temperature. However, the formula is, well, shakey at best, especially on silicon-based stuff.

And if a device is specified for 0 to 85° operation, giving the MTBF for 85° means to either really test a device this long, or has it been tested at 100° for a week and failed? And in the latter case, couldn't it have failed at 85° after a week too? Sure, the laws say it is legal to stress a device until it breaks and then multiply the time it did stand the test by the temperature difference it has been stressed above the normal operating temperature.
And this works under a few border conditions. Including that both, normal operating temperature and test temperature are far below any physical breaking point. And that there is an increased degradation by temperature that can be expressed with this formula.

I don't think that this applies to silicon and its microscopic workings in the way it was originally meant for macroscopic devices (motors, springs, etc.)

A change in temperature, if below a melting or avalance point, may not change the life expectancy at all, above, it may end the life of the device immediately even if it would have unlimited life else.

So I only believe in real-world tests under typical conditions. My customers won't be happy too, if a device fails after a short time when it should 'theoretically' have lasted much longer. If I then tell them that in theory it cannot have failed, well, imagine their response.

However,

jborgeson said:

these endurance characteristics only apply for a "same-state" write (most commonly a refresh/read operation).

That is an important information. Including the conclusion:

jborgeson said:

If you write a different value into the memory again, then the endurance starts over again like it was never written to.

So if you "XOR 0xff" the fram area twice on program start (from SRAM function) it will make the device endure forever? Really interesting.

I'm a bit surprised about this. I had expected that state changes wear the cells out. And a destructive read is a state change. At least for one state. So e.g. reading and writing a '0' cell won't, while it will for a '1' cell will, as the '1' is destroyed when reading and restored after this. Or something like that. But well, i don't know much about the physical workings of FRAM.

JMG,

You are correct in stating how we arrived at the current numbers.  You can also see from the tables in the Quality and Reliability document on FRAM presented here exactly where the data comes from and how it was obtained.

 

FRAM Quality and Reliability Document

 

What I am referring to for the second part of your reply for the "same-state" vs "opposite-state" writes is described in the section on imprinting.  Basically, imprinting occurs if a devices stays too long at a high temperature, aka it is written to many times in the same state.  This test loop occurs to basically stress how far we can go on same state write and then still reliably write to the opposite state.  This translates into what I described above. 

 

I am sure you will get a lot of your detailed answers out of this document.

Thanks,

Jacob

jborgeson said:

... It's strange how even quoting such an astronomical number as 10^14 still caused people to pull out their calculators and work out some rough math.  It's also great when most of those calculators are made by us :).

Every time I breath, I suck in 2 or 3 x 10^22 molecules of air. Am I astronomical?

 

jborgeson said:

Basically, imprinting occurs if a devices stays too long at a high temperature, aka it is written to many times in the same state.  This test loop occurs to basically stress how far we can go on same state write and then still reliably write to the opposite state. 

So this means that
1) it doesn't matter for a refresh write, as there is no state change. So code memory won't fail during continued operation
2) if after exceeding the endurance, code is rewritten, causign a state change, this might fail (e.g. a firmware update), but a few intermediate forced state changes will fix it, so it isn't permanently broken?

If this is true, BSL and application can take some precautions and enlarge FRAM endurance to virtual eternity.

jborgeson said:

I am sure you will get a lot of your detailed answers out of this document.

Unfotunately I'm not an IEEE member or library subscriber, so I don't have access ot this document.
It's not so important I'm interested in background info, but I'm not dying for it :)

Jens-Michael,

 

This is pretty much correct except for some few details.  There are two ways to fail:

Thermal Depolarization: This is where the FRAM molecule/capacitor fails due to the fact that the physical difference between one polarized mode and another is too small for the detection circuitry to be able to identify.  This can happen because of thermal exposure before being written, and is corrected once the molecule is polarized (written) to the same state.  This applies to the Retention specification of 10 years more than the endurance specification.

Imprinting: This is where the molecule becomes "stuck" in a certain state and cannot be fixed through a write operation.  This is generally where we get our endurance numbers from.

 

Hope that clears it up.

 

Thank you for your detailed explanations.

Well, temperature is a statistical thing. Even near 0K, it is still possible that a molecule is fried while all others are freezing. Just not very likely. So indeed, an individual FRAM molecule may cross the Curie-temperature (or the FRAM equivalent) and lose its magnetization while its immediate surroundings have 'room temperature'.
The less molecules form a functional unit, the more likely a temperature-based failure is. And if enough 'structure' is left for the whole unit, it will be corrected on a rewrite.

Imprinting, however, is indeed the major problem. Does it happen because of physical/chemical destruction of the molecule (temperature/mechanical stress induced decay)? Molecules usually do not change their behavior as long as they are still the same molecules. Either they continue to exhibit the same physical behavior or they have been transformed into something else.

Well, I think this has gotten far (and deep) enough.
Thanks for all of this information.

I think, FRAM is a great thing. Implementing soem emchanism to speed it up a bit (liek the flash access cache used in the 5x flash.based MSP family) would be good. Currently, clocking an FRAM MSP with >8MHz will actually slow it down (depending on the code).
Another good thing would be to replace the info FLASH of other MSPs by FRAM. Fast random writes to non-volatile memory would allow quick saving of relevant data in case of a power-loss (or data could be updated all the time during operation). Would be even better than an EEPROM.