Sonsivri

I have read that reading a FeRAM deletes the current value (if it is a logic "1") https://it.wikipedia.org/wiki/FeRAM, but no mention about this i done in the datasheets that compare the I2C reading of the memory almost identical (although much more faster) to reading an I2C EEprom.

Can anyon clarify this point? Does the FeRam I2C memory refreshes the value after reading to avoid deletion?

If you use for example a TI MSP430 controller with an integrated FRAM it has an inherent mechanism that restores the original data after reading.
That might not be the case if you use just an FRAM, I guess you have to rewrite after reading.

In the I2C FRAM modules I have read, no mention is done about this fenomena... it is somewhat confusing...

Doesn't that effect relate to the (very) old core magnetic memory?

As far as I'm aware, the current FRAM devices do not suffer from this effect.

Reading is advertised as being full speed - But they could hardly say that if every read had to be followed by an immediate write.

Exactly. Probably the best way to go is to try to write, read and re-read to see if anything has changed.

The current parts don't erase on read. I don't think the manufacturers would sell many if they did!

probably it was a problem of the early FRAMs...

Yes, the FRAM loses info after a read, and must be  written back. Thankfully, the MSP430 FRAM handles the process automatically. You can find more info in http://www.ti.com/lit/an/slaa649/slaa649.pdf
Hereunder an excerpt from it:

... In the process of reading the data, the crystal that is polarized in the
direction of the applied field loses its current state. Hence, every read must be accompanied by a writeback
to restore the state of the memory location. With TI's MSP430 FRAM MCUs, this is inherent to the
FRAM implementation and is completely transparent to the application. ...

Best


Posted on: February 28, 2015, 12:02:34 00:02 - Automerged

---

Additional info:
The standard I2C FRAM datasheet from Fujitsu don't mention the rewrite process. But at Spansion (which is Fujitsu!), they describe it, in chapter 3.2 of the following document (The number of Rewrite operations)

http://www.spansion.com/marketingdownloads/appnotes/public/fm3/an706-00053_control_fram_by_i2c_and_spi/an706-00053-1v0-e.pdf

I'm going to use this type of FRAM
FM24V01-G

No mention about the need of Rewrite is done in the DS, http://www.cypress.com/?docID=48193

it's a direct replacement for an I2C EEprom, it has the rewrite after read mechanism internally, you don't have to do anything from the outside. Just write and read.
We used a similar type to store debugs in the event of power failure in a device, because you can't use flash memory in the short time between a power bad signal and loss of power, it's just to slow.
With an FRAM you are fast enough, worked great.

Hi, Droneman1982,
You can take a view to the new Everspin MRAM devices like  MR25HXX.
There are some SPi and parallel  memory's  easy to use.
See at manufacturer www page.  www.everspin.com

Thank you all guys :-)

The purpose to use the FRAM (actually my initial idea was to use a DRAM) is to buffer/store data between two microcontrollers. One microcontroller is devoted only to IMU calculation and ESC control (for a drone), that needs minimum delay to ensure stability, with the attutude setpoints and PID parameters read from the FRAM (set by the other "AI" microcontroller). This way the IMU operates ad the fastest speed and the "IMU" microcontroller reads data only when it is ready to do it. The "AI" microcontroller reads GPS data, RC data (in ppm or SBUS) and the angle (or quaternion) from the "IMU" microcontroller (to parse it to telemetry or OSD and to check if there is some motor problem).

The rest of the memory of the FRAM (thanks to its non-volatility) will be eventually used to store "no fly zones" and "magnetic declination data grid" and other useful parameters