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?

Hello,

The DQ output level of the FM28V202A IBIS model  in Slow weak mode, is equal to 2V maximum, whatever the load, which is lower than the minimum level guaranteed by the datasheet 2.4V for -1mA and VDD=2.7V. Did we do something wrong?

Thank you in advance for your help,

Best regards

Pierre

Hi all,

I am trying to interface a FM24V05 to an STM32H723 on a custom PCB, but for some reason it will not acknowledge to any write/read requests in the addressing phase. I have confirmed the address is correct and it will not reply to any of the reserved slave ID's either. I have swapped out the chip for an FM24V10 as well as other chips from a different batch. Further, I have a CY8CKIT-044 and swapped the FM24V05 onto it and found it was successfully addressed by Bridge Control. 

Attached is a image of a signal analyser readout of the transaction running at 100kHz (I have tried using lower frequencies) and probed directly on the SO8 pins to rule out bad solder joints. A 3.3V supply is provided to the chip with a 0.1uF cap right next to it and was observed with an oscilloscope showing no obvious power problems between VCC and GND.

There are other devices on the bus which are all successfully talked to (I disconnected them to rule them out), with 2k7 resistors pulling the I2C lines high.

I took a signal analyser capture of the chip talking on the CY8CKIT-044 and saw no real differences and compared the schematic/PCB files and again saw no real concerns.

This has stumped me for quite a while so any help would be great!

Cheers,

Luke