Non Volatile RAM (F-RAM & NVSRAM) Forum Discussions

Hi,

I am running the CY14B108N at 40Mhz (25ns), with VCC of 3.6V, and I am seeing ~95mA on power supply, during a read opeartion with outputs floating.  I was expecting less than 75mA! I have tried remvoing external pull ups, and VCAP. If I lower speed to 100kHz I see ~25mA which is about the amount that the Max condition appears to be over reading.  The ISB (Satndby current) reads ~2.5mA which is good and under the 10mA limit. Devices are functional.

Has anyone else ran into this before?

Thanks,

Rad

Hi,

I write a sequence as below, And I am using CY14B512Q2A IC with out auto store circuit.

step 1:  send 0X19 ,       //Disabling auto store

Step 2:  send 0X3C,      // store it in nonvolitile memory

Step3:  write "Ganesh" into address 00 to 05,     // writing some Data in IC using write command 

Step4: Swith OFF the module   //switch OFF power for the circuit.

Step5: Switch ON the module  //Switch ON Power supply.

Step6: Reading from the adress 00 to 05, and i get "Ganesh".

if you see the above steps what i did  is writing a data("Ganesh")in SRAM as per data sheet. but after disconnect the power this data should not be there in the particular adress.  but in my case the data is there. and i can read it every time. 

Please anybody tell me what is mistake in the Steps i follwed.

Hi,

I am having difficulty sending software controlled autostore disable.  I think I am interpreting the datasheet reads incorrectly. Is there a more detailed document regarding the software commands?

The data sheet states that sequential reads of 0x4e38, 0xb1c7, 0x83e0, 0x7c1f, 0x703f, 0x8b45.  The CY14B108N has 19 address pins while there are only 16 pins defined with these hex address. 

I have assumed that A18,A17,A16 are set to zero and not used.

A15            -              A0  <-address bits used

0100 1110 0011 1000 <- binary first read

    4       E      3        8    <- First read

Thus,

(A15 = 0, A14=1, A13=0, A12=0) = 4xh

(A11=1, A10=1, A9=1, A8=0) = Exh

etc.....

This should be straight forward, but I notce there is small print in datasheet under truth table that states.....

6. While there are 20 address lines on the CY14B108L (19 address lines on the CY14B108N), only the 13 address lines (A14–A2) are used to control software modes.
Rest of the address lines are don’t care.

Again, there are 16 bits defined in the hex value but now with this statement only 12 bits matter?

Can someone please explain this?

I have attached waveform of the 6 reads, does this look correct?

Thanks,

Rad

Hi,

Anyone have any ideas of what I should check, regarding why my first address always contains 0000h upon power-up restore, even though the rest of the locations appear to contain what was stored using autostore. All of my SRAM writes and reads are correct it is only upon restore that the first address read is incorrect and all zeros.

Thanks,

Rad

I have a table stored in part of the STK14CA8-N25I nvSRAM.  This table is stored first time at the production line at the begining of the product life.  The table is NOT supposed to be updated during the unit life cycle. Every power-up the table is being read from the memory and used by the product functionality.

Unfortunately, in several units the table was disrupted and few bits, in random places, changes their value from '0' to '1'. (The memory nas NOT erased or "run over", just disrupted in some random bits).

It sounds very similar to the Single Enent Upset (SEU) described in AN15979 but it occurs too much frequent.

Have you meet  this phenomena before in nvSRAM devices ? do you have recomandations how to solve this memory disruption ?

Dear Sir,

    I am using the CY14B101P for one of application for data logging. Following design support from you:

1.       Operating voltage: I am planning to provide 3.3V regulated voltage to the NVSRAM.

       Is it okay or any suggestions?

2.       Controller Interface: My uC operates with 5V.  5V-3.3V & 3.3V-5V converter using transistor (BC848) were used in between the uC & NVSRAM.

    Is it okay or any suggestions?

3.       3.6V battery Ni-Cd battery, I am planning to provide to NVSRAM, after suitable voltage drop (3.2V), using 2 diodes in series.

     Is it okay or any suggestions?

4.       I am planning to charge the Ni-Cd battery using 5V supply with a suitable diode & resistor combination. Shall I charge the battery, when connected to NVSRAM, with the presence of 3.3v supply to NVSRAM?

Kindly send your reply.

With regards,

Jayaraj.A

Hi,

I'm running linux on an MPC8308, trying to access a CY14B256Q2A SPI nvSRM and I'm having dificulties.  To avoid having to write my own driver, I'm utilizing an existing Freescale driver for the SPI controller in the 8308 (spi_fsl_spi), and an existing interface driver that sits on top of that (spidev specifically if it matters) and I'm unable to even read the status register of the nvSRAM.  I'm pretty sure the problem is in the way these two drivers work but I want to confirm it with you since the datasheet for the nvSRAM isn't explicit either way.

To read the status register the device needs to have CS asserted, SPICLK started, and 0x5 clocked onto MOSI.  On the first clock following the read status reg command the MSB of the status register gets clocked out on MISO.  My question is, what happens if the clock stops for a period of time between the LSB of the commnd and the MSB of the result?  I've scoped the signals and what I see is eight clock pulses with the read status reg command, then clock goes silent for about 20msec and then starts back up (CS is held low the entire time), but it appears no data is clocked out of the nvSRAM when the clock starts back up.  Does the part require that clock be continuous for the entire transaction?

The fact that burst reads are possible as long as CS is held low implies that the clock can start and stop without impacting the part, but it's not totally clear.

Thanks.

Bruce

unable to write in the alternative locations after 0xFFFEO in CY14B108K nvRAM.. attached the screen shot..

please help me how to resolve this...

Thanks.