We have an FM25L16B in our product. I want to know how long it takes the memory chip to write one byte to the cell of the FRAM after it has been transferred to the memory chip via SPI. I need this information to calculate the probability that a power interruption will interrupt this write cycle.

A similar question was asked in https://community.infineon.com/t5/Non-Volatile-RAM-F-RAM-NVSRAM/FRAM-access-time/td-p/119910, but the write access time was not given by @PradiptaB_11 .

Thanks,

Daniel

Hello,

AC characteristics for SPI FRAM (FM25CL64B) is based on signal rise/fall times of 5ns, which includes CLK signal as well.

What is the max. acceptable clock rise/fall time, supported by the device?

Thanks in advance
Frank
 

Could you please provide us the latest REACH-233, ROHS, TSCA coc’s and Material Declaration Sheets for the below parts #

FM22L16-55-TG

FM22L16-55-TGTR

I've run into a problem with some FM25CL64B-GA chips in a new device.

To initialize the FRAM (not trusting the factory default values), I read a specific location (last 4 bytes) and look for a specific pattern (0xBEEFF00D), and if it isn't there I set the complete memory array to 0x00, then write my pattern to the appropriate location. On the next start, I look for the same pattern at the same address and, if the pattern is there, bypass zeroing out the array.

The problem is that I repeatably read garbage instead of my pattern at startup, and zero out the array erroneously. The chip seems to not be ready to be read. I checked the documentation and 001-84477 Rev. *J says that I need to wait a minimum of 1ms from power up to first chip select (tPU) which is what I had coded.

I'm running the chips at 3.29V (measured with a Fluke 87V), 16MHz on SCK, medium SPI pin drive current giving a good voltage swing to both rails and square edges, room temperature. To be sure that it just wasn't a bad chip, I had our tech swap the piece with another from the same lot (date code CYP 1619)

Since my micro processor has a reasonably stable clock and a 1ms tick, I delay until the top of the next tick before accessing the memory. I still have the startup problem. Okay, the processor may boot earlier than the FRAM, the tick counter may not be precise and it might tick early by a few microseconds, so I adjusted the startup delay.

So I tried increasing the startup delay to 2 and 3ms but read the wrong value, and finally at 5ms the system started reliably correctly in my tests, so I increased the startup delay to 10ms and the system starts correctly in testing. No other changes to the code or hardware. I also checked to see if the system tick (1ms tick) was correct, yes it is (within a microsecond).

Just increasing the delay before reading the FRAM fixed the issue.

Oddly, the startup time (tPU) was 10ms in the original version of the documentation, but reduced to 1ms in version *A in 2013.

So, my questions: the value of tPU is 1ms minimum, what is the recommended typical value? 5ms (which is greater than 1)? 1000ms (which is greater than 1)? Does it vary with temperature? Are there other parameters that affect my choice of delays to meet tPU?