Nvram write modes and problems

That sort of thing will be in the datasheet.

When the power goes then whatever is writing the page stops writing. I don't know if the whole page is discarded on your NVRAM but I wouldn't trust what was written anyway - you can't tell at what point the power failed even if the page stored everything up to the power failure. How do you know the 20th byte was written but the 21st didn't make it - on the next startup you have a mixture of old data and new.

Byte writing means you know where you are and a power failure only affects the last byte.

I would use byte mode myself. This data is clearly important data (or else you wouldn't want it to be non-volatile) so why take the risk. NVRAMs are not that big so you won't be writing a lot of data and so the speed hit won't be huge.

Assuming byte mode then it would depend on what device was writing to the NVRAM. I had a tricky problem once where an FPGA with a 3.3V core and 5V driven pins was writing to a 5V NVRAM. When the power failed then the 3.3V failed first which effectively made the 5V pins all go low. This brought down the chip select and the R/W line to the NVRAM and caused zero to be written to location zero before the 5V collapsed and the NVRAM saved everything. However, the timing was critical and if a write was underway at the time of the power failure then the write finished because there wasn't time or voltage to bring the CS high again to write a fresh byte. This was solved in the end by ignoring data in location zero which is far from satisfactory but it worked ;-)

For the previous problem we set up a simple 555 timer circuit which pulsed power to the system for a few hours/days and the system repeatedly ran self-test until it spotted a problem.

You need to get a scope hooked up to the power and control signals to the NVRAM. A logic analyser won't do because you want to look at the analogue values.

I have also experienced corruption in NVRAMs when they get near to the limits of the maximum temperature they are rated to. Watch out for that.

You might get more specific and helpful responses if you specified the part number of the NVRAM.

Mark Borgerson

1. If you don't have a brownout supervisor, your CPU can do crazy things during the power down and power up. This can very well cause the occasional NVRAM corruption.

1. Keep the NVRAM in the write protected mode at all time. Enable write only for a short periods when you actually need to write something into it.

2. The write procedure should be transaction based. So the accidental interruption of power should not corrupt anything.

1. Watch for the system issues like improper power or clock lines layout, interrupts happening at the wrong time, watchdog timeouts, software bugs.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

ssubbarayan wrote:

Dear experts, Thanks for your replies.

1)We did try to simulate brownout tests by varying voltage to the Nvram when write is going on.This was not able to produce the problem. 2)Mr.Vladimir,can you please explain your point number 3),I would like to understand more about it from you. 3)We use ST's M24128BW chip for NVRAM. 4)We are currently addressing the NVRAM via I2C.Will there be a possibility of data corruption due to I2C?We are using I2C to communicate to multiple components.Nvram is one of them.We have taken care in software by writing to NVRAM after using a semaphore.Can there be any problems in the hardware introduced due to I2C?

Regards, s.subbarayan

See below. Your articles should always stand by themselves.

-- If you want to post a followup via groups.google.com, ensure you quote enough for the article to make sense. Google is only an interface to Usenet; it's not Usenet itself. Don't assume your readers can, or ever will, see any previous articles. More details at:

-- Posted via a free Usenet account from

This is not NVRAM, this is an EEPROM.

That also explains your 'page write', 'byte write' and 'erase' comments earlier. Those already made me think about EEPROM as they did not make sense to me in NVRAM context.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Hi CBF, Can you please elicit on how it should have been posted?I just clicked the reply link in Mr.Vladi's reply and posted this.

Regards, s.subbarayan

Ok stef, I stand corrected.Here in our project we keep refering to eeprom as nvram as it looks similar even though not exactly. Anyway do you have any suggestions given that its an EEPROM?

Regards, s.subbarayan

That's a habit you should get out of. NVRAM looks like regular RAM in use but on power failure it transfers the contents of the RAM so some non-volatile storage within it. It then transfers this stored data back into the RAM on power up.

EEPRROM is different and is often accessed by I2C, which is what you are doing. Just because it is a non-volatile storage device doesn't mean it is NVRAM because it is not random access. You'll confuse everyone if you refer to it as such.

The advice given regarding page vs byte transfer is still valid. You need to monitor your I2C signal to see what it is actually sending during power failures. Alternatively, stick another EEPROM on top of your existing one but leave it's output unconnected. Compare the contents after a period of running.

That may work on an SPI device with separate SDI and SDO lines. With I2C, SDA (and SCL) is always bi-directional.

Always make sure you don't have power fails during write operations and make sure you obey all timing and precautions in the datasheet.

If you can't guarantee power during writes, store at least 2 copies of your data and make sure those copies do not share an EEPROM page. Implement a mechanism to check if a copy is valid, for example by calculating and storing a CRC value over each copy.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

It's non-volatile, random access and rewriteable. Sounds like nvram to me. I don't think write time is valid criteria for determining if it's nvram or not. There are multiple kinds of NVRAM with battery backed and FRAM having the fastest program times.

I'm not sure I'd consider flash to be NVRAM simply because it's write/ erase granularity is large. I do use NVRAM as a generic descriptor that includes EE, FRAM etc.. though when I don't wish to get into the details specific to a particular type.

Robert

EEPROM write operations should be transaction based. Here is a simple example:

1. There are two locations in the EEPROM for every object.
2. Each location has a validity flag. If the flag is set, the corresponding object is considered to be valid.
3. Normally, one object is valid and the other one is not.
4. The write operation sets the invalid object, then sets the validity flag for it, then clears the validity flag for the previously valid object.

Thus, if the write transaction is aborted at any moment, you always have the backup of the previous data.

VLV

... but it's not really "memory". I2C EEPROMs and other serially attached devices like them are non-volatile *storage*. They're really too different from actual RAM to be called NVRAM.

Sure it is. The size of the bus shouldn't have any bearing on the issue. Note Philips has sold IIC devices for some time that it refers to as RAM.

I can see the distinction you are making. I sympathise but I'm not sure I agree. If you make a distinction based on ease of write then flash becomes non-volatile storage rather than memory. Not a distinction I'd be happy with.

I don't agree. NVRAM is simply an intermediate storage form that sits on the spectrum between between volatile RAM and mass storage. The distinctions are rather grey but NVRAM includes EE and FRAM as well as BBRAM as far as I'm concerned.

OTOH, I'm not going to insist you agree with my definition only realize others don't necessarily share your narrower definition.

Certainly the OP should have at least mentioned the technology of NVRAM being used but I don't believe he should have been corrected on his terminology.

The boundaries between memory types is rather fuzzy and shows every sign of getting fuzzier in the future.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

I'm not too happy with calling EEPROM random access. Sure you can read any location you want, but to get any performance out of them you'll want to read them sequentially. And to get something written, you need to send a few commands first, wait for previuos writes to finish and only write a single page at the time.

To me, the distinction is in the technology: EEPROM, FLASH, FRAM, RAM and if you add battery backup to RAM you get NVRAM.

FLASH is only random access when reading, writing is very different. When running code from a FLASH, I'm happy with refering to it as ROM. When I need it to store data, it's FLASH again or maybe NV storage.

That would be my definition of non-volatile storage, with NVRAM being one of the possible flavours.

But where is your boudary between NVRAM(storage) and mass storage? How do you call an SD FLASH 1GB card? There is not a whole lot of difference between updating a sector oriented FLASH device and a harddisk, why would one be intermediate storage and the other be mass storage?

OK, we agree to disagree then.

The OP experienced memory corruption, so the first thing that you would like to know is the type of memory. Calling it NVRAM confused me enough to not know for sure what he was talking about, and I'm sure I was not the only one. So I stand by my correction.

I find them mostly clear enough for now, but that may change. ;-) For me, only FRAM is a bit fuzzy. I don't have a real problem with calling the parallel version NVRAM.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

My mental picture would be something along the lines of Volatile RAM - Writeable, random access, usually 'close' to the micro, addressable in some unit sensible to the micro, typically bytes or words. And of course volatile. Accessed frequently. NVRAM - As above but retains it's information even with power off. Associated with 'small' amounts of parameter or information needed to be retained across power cycles. Often accessed only to save/restore state. Mass storage - generally addressable in larger units, often removeable. Associated with 'large' amounts of data.

Like you I'm not really comfortable describing Flash as Flash RAM although it is at least in some sense accurate. I'm just too used to thinking of it as more like an analog to ROM.

Basically we use the term NVRAM for two purposes, you use it more to describe a technology and I to describe a use pattern. I don't think the term is really well defined for either of us.

Maybe a new set of terms needs to be defined to separate the usage from the technology.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

But the *type* of bus should. As soon as the line(s) you connect something to are not one of the CPU's memory buses, accessed by memory read/write instructions of the CPU, it's not memory, but storage.

To provide a testable definition: it's memory only if it can hold some of a C program's variables.

That's quite irrelevant, or at least it should be. I hope we can agree that we should *never* let marketroids define the meaning of technical terms, right?

Parallel flash is memory. To be precise, it's PROM with a memory-mapped programming interface.

Serial flash OTOH is a random-access mass storage device, all practical intents and purposes equivalent to a hard disk.

Small serial EEPROMs are somewhere in between, but more similar to serial flash than to parallel.

Point taken.

Myabe not a good test. A sufficiently creative compiler could use external storage as an extended address range ;)

Yes, but not irrelevant. My point was that there are two definitions of novram being used, one based more on tight coupling to the micros bus and relatively high speed writes. The other based on usage to store operating parameters.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

Byte Craft's compiler do exactly that. User defined address space allows applications to create storage devices and tell the compiler how these new memory area's are to be accessed. The compiler will then allocate this space as it would any named address space.

The two most common uses I have seen to NVram with direct read's and some driver for writes.

The second most common use is most of the LCD displays have RAM for a full sized display but are generally quite small. The remaining display buffer area is used as storage.

A few years ago this was formalized as part of ISO/IEC 18037 C standards for embedded systems.

Walter Banks