Non Volatile RAM (F-RAM & NVSRAM) Forum Discussions
I see other posts asking if the CY14E256LA-SZ25XI was obsolete and Infineon states full production. Digi-key and Mouser list as Obsolete. Digi-key sent me the attached list (PD220902A) of Product Discontinuation. It lists the CY14E256LA-SZ25XI as being obsolete with the 3.3V chip (CY14B256LA-SP25XI) as the Next Best Alternative Part.
Is this list of discontinued Memory Products correct?
How was this list generated if the part had not been Discontinued.
Should I make a case to redesign all our assemblies or are these parts not be in Discontinued?
Soft Error Rate discussion on NvRAM in thread from 10/16/2018 06:00PM provided a Report file to the discussion initiator. Are similar SEU/SEL report files available on NvRAM parts STK14C88-3NF35I and CY14B256LA-SZ25XIT?
- CY15B004Q does not have unique SN features, neither the OP commands regarding to this functionality.
- CY15B004Q does not allow fast reads or writes.
- CY15B004Q has only 4Kbit (512 * 😎 instead of 1Mbit (128k * 8).
- CY15B004Q has a logic bug in the state machine, where the OP code byte 0x0A does not trigger clearing the WEL bit.
- CY15B004Q has 0 - 16 Mhz speed instead of FM25V10 0-40Mhz.
In the Write operation, if / WE is asserted and then negated earlier than the Min value of tpwe,
Is the content of SRAM at the address undefined? Or does the previous value remain?
If it is undefined, if the power is turned off and then turned on in that state, the SRAM → nvSRAM store operation (@power off) will be performed as an indefinite value.
Does nvSRAM → SRAM recall operation (@ power ON) and nvSRAM operates with an undefined value?Show Less
we have a prototyping board equipped with fram (part number cy15v108qn-20lpxi). The mcu controller is ti's cc2640r2f. I have tried both gpio bitbang and spi hardware to read status register. The results are the same. the first byte, 0x05, is issued from mcu and the fram chip did respond a byte, an 0x0c, which is an illegal value according to manual, since the bit 6 is not set. Also bit 2 & bit 3 is not the default value (supposed to be 0).
Attached are waveforms I photoed from my osilloscope (sorry that i have only a low-cost, dual-channel one at hand, but I think it is enough for the job). One shows the first byte is 0x05, correctly issued from the host. The other shows the second byte replied from fram. The wave form looks OK but the value 0x0c is incorrect according to datasheet.
Also, I have tried to read device id (0x9f) and unique id (0x4c). Both commands returned only zeros, which seems to be incorrect.
any good explanations for the problems? or any timing error in wave forms? or the chips are broken? shed me some light.
I am trying to read the Device ID from a CY15B104QN-50SXA chip and am getting out 0x402CC27F7F7F7F7F7F, which is the LSB to MSB read of the actual device ID listed in the datasheet, 0x7F7F7F7F7F7FC22C40. The datasheet claims the chip should read it out MSB to LSB, is there a reason this wouldn't be the case? Are other read/write operations affected as well?Show Less
A customer tells me Cypress Part Number CY14E256LA-SZ45XI is obsolete.
The Infineon website says it's 'active and preferred'.
Infineon support says they 'do not support Cypress components yet '.
Is Cypress Part Number CY14E256LA-SZ45XI obsolete or is it still available in the 32-pin SOIC?Show Less
Hey guys, I see FM24C16-P(8 pin DIP) is obsolete on digikey/mouser. I found an alternative FM24C16C-G which is a 8 pin soic . I just wanted to confirm except for the package type dfiference(SOIC vs DIP), rest all is same for both the chips.
I am in need of a IC FRAM 8Mb SPI 20MHz 8GQFN memory. I planned on using the Infineon part #CY15B108QI-20LPXI, but it is out of stock everywhere. I am having trouble finding a replacement from Infineon or other competitors. I already need it to be able to operate in high temperatures (around 120C). If anyone knows of a replacement or has any recommendations, that would be highly appreciated!
We have seen the following situtation when using a CY15B104Q-SXI which is accessed by an FPGA on a board with stable power up timing. After a an operation which writes ALL of the locations with a three (3) pass method with 0x00, 0xFF, and 0xAA (the FRAM will be left with ALL locations at 0xAA) we have found errors in the data read from the FRAM. It appears that the data read out by the FPGA from the device into a Block RAM buffer inside the FPGA is incorrect. We have the actual device in hand. Also, during debug of our code it was possible that WRITE accesses ocurred at a location past 524,287 (rollover).
Here are some details of the operation :
The power up code sets the WRDI to have BP(1:0) set to "00" : No Write protection
The WRITE operations are all performed with a WREN command and then a block WRITE with the entire memory length written in one block. There are no individual WREN WRITE operations at a single address. The FRAM is written with one WREN/WRITE of the entire 512K size with same data witten in three passes : 0x00, 0xFF, and last 0xAA.
The READ operations which _export_the_entire_memory_to_a_host_PC_over_a_UART port from the FPGA are individual READ operations at a single address and the output looks correct.
The READ operations which _load_a_portion_of_the_FRAM memory to the BRAM inside the FPGA are block READ operations from an offset address to a small range of less than 16K Bytes. When we export the contents of the BRAM (loaded from FRAM) we see corruption in the form of the AA bytes occupying a large section of the expeted data, followed by the remainder of the expected data. THe BRAM is loaded with the fast read option.
Now, we have shown that when we BLOCK WRITE using the three (3) method (again, all are BLOCK WRITEs of exact length of the full FRAM size starting from addr 0 and ending at 524,287) with write timing obeyed (CS high duration between Block Write operations at 25MHz SPI timing) gives incorrect READ data from the BRAM buffer to the host. We can see that some swaths (contiguous regions) still have incorrct data in them from a previous pass.
However, we have found out that when we change the operation of the FRAM three pass to finish with 0x00 (00's left in entire FRAM space) the READ operations are performed correctly for all locations.Show Less