EEPROM data backup

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I looked through the datasheets and App notes and couldn't really find a straight answer, so here goes.

I have a design which incorporates an atTiny2313A, operating at roughly 5.5V nominal. The device contains 32 bytes of SRAM, which upon some signal I wish to backup any changes to the EEPROM. The catch is, the signal will come shortly before I lose power. How much time I have will depend on how long a fully charged capacitor can retain voltage.

So the questions are as follows:

1) How much time do I need? The datasheet claims that an erase/write cycle takes 3.4 ms. However, elsewhere in the documentation there is a discussion of a "page" consisting of 4 bytes. This implies that perhaps only 8 writes are necessary to backup the data. But I'm not clear that this isn't an external programming mode that doesn't apply to EEPROM writes from within the code.

2) What is the minimum voltage required to safely write to the EEPROM? Based on looking at the datasheet I'd say 2.7V, but it doesn't explicitly say that.

3) Assuming I am running on the 8MHz internal oscillator, and doing nothing other than writing data, what is the minimum current consumption I can expect to achieve? Is there a particular technique to do so.

I'm figuring the capacitance I need will be I(min) * time (required to write) / (5.5-V(min), plus some safety margin.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your general general reasoning appears to be fairly sound. To
come up with precise figures (bearing in mind that it is better to come up with a generic answer) is a bit tricky as it will very much depend upon specific controller, temperature, current status of I/O , LEDS, pull-ups etc.
So my suggestion is to assume that it will work, write the code
and then do some tests and get some correlation between bytes saved successfully and power supply capacitance.
Also read application AN180 regarding brown-out to retain integrity of the controller at low voltage. Don't forget to publish your results & code.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a large number of other constraints that I did not list. Knowing how much capacitance is a serious design issue, and not a mere afterthought of adding more until it works. If I need more than 300 uF this may not work at all for my application, therefore I need at least reasonable numbers to work with.

In terms of the power consumption, in case I didn't make it clear. Once I receive the signal, it is my intention to do everything possible to dump the data to the EEPROM before I run out of voltage. I do not anticipate any significant load other than the chip itself. If I can shut down the chip (all except the EEPROM write) and then wake it up on an interrupt, I will do that. Hence my question of what is the minimum current I can expect to be able to achieve given a 5.5V supply on an atTiny2313A. I have no control over temperature, and would expect it to be somewhere within the industrial (-40 to 85C) corner.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I have a large number of other constraints that I did not list.

We are not mind readers!

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

1) How much time do I need? The datasheet claims that an erase/write cycle takes 3.4 ms. However, elsewhere in the documentation there is a discussion of a "page" consisting of 4 bytes. This implies that perhaps only 8 writes are necessary to backup the data. But I'm not clear that this isn't an external programming mode that doesn't apply to EEPROM writes from within the code

There are threads, fairly recent too IIRC, on the [supposed] "page" aspect of AVR EEPROM. Search them out. Short answer to your situation: Fuggedboudit. Note that some time can be saved by pre-erasing. Note that some toolchains will have a read-before-write to eliminate wasted erase-write cycles.

Quote:

2) What is the minimum voltage required to safely write to the EEPROM? Based on looking at the datasheet I'd say 2.7V, but it doesn't explicitly say that.

See the other current thread about racing powerdown. If you do not have a brownout detector enabled, your AVR >>will<< experience erratic results and one of the common symptoms is EEPROM corruption. That thread also talks of measuring the voltage as early in the supply chain as practical. I've outlined the racing procedure before. Early loss-of-power detection. Turn off powersuckers. Only write what is needed. Generally with modest Vcc caps you end up with ~100ms. As suggested, simply test in your app. That should allow for some dozens of writes, and many bytes are probably not changed.

Quote:

The device contains 32 bytes of SRAM,

I could read that several ways. That model has more than 32 bytes of SRAM. Is it 32 bytes that you desire to save? That makes a bit more sense, but seems quite a lot to me. Even in my large apps I have less "critical" data than that.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, what I did not say is that I am attempting to replace a battery backed up (32x8) SRAM in a current design. As a result, I'm under severe space constraints. In fact, I'm only considering a Tiny2313A because its available in the 2M20 package (3x3 mm). My entire "device" must fit in an area smaller than a 18 pin DIP. I suspect I will only have room for 4 10V 100uF ceramic (X5R) capacitors (at best), which means total capacitance may be on the order of 200 uF.

I'm intending to put the data lines on one port, the address lines on another and the control lines on a third. I will run by simply polling the control and address lines. I do not know if all 32 bytes are used, or if they all need to be saved. My guess is that at least 8 bytes need to be saved, although they may not change between power cycle and hence may not need to be written out.

theusch wrote:

See the other current thread about racing powerdown. If you do not have a brownout detector enabled, your AVR >>will<< experience erratic results and one of the common symptoms is EEPROM corruption. That thread also talks of measuring the voltage as early in the supply chain as practical. I've outlined the racing procedure before. Early loss-of-power detection. Turn off powersuckers. Only write what is needed. Generally with modest Vcc caps you end up with ~100ms. As suggested, simply test in your app. That should allow for some dozens of writes, and many bytes are probably not changed.

I don't understand this. Either the AVR will have a chance to complete the writes or it won't. The brownout detector may stop the writes in time not to corrupt the data, but the data will still be lost. As previously mentioned the only "powersucker" will be the MCU itself. Hence, when I detect a power down, if I could put the MCU into a low power mode that should drastically extend my available time. Detecting power down is a whole separate matter. If I'm attempting to detect a power down by looking at the supply voltage I suspect I'll be *WAY* too late to do anything. I believe there are other signals I will be able to monitor (elsewhere in the system) that will allow me to detect power down before my supply collapses much.

It's kind of hard to imagine getting ~100ms out of a "modest" Vcc cap. According to the datasheet, under normal operation, at 8MHz 5.5V operation its drawing around 5mA. Again, I don't know if it would be drawing more (from the EEPROM write) or less (from some reduced power mode). Based on the formula I wrote up before, you'd need 180 uF to last 100ms.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Based on the formula I wrote up before, you'd need 180 uF to last 100ms.

Quote:
I suspect I will only have room for 4 10V 100uF ceramic (X5R) capacitors (at best), which means total capacitance may be on the order of 200 uF.

I make that 400 uF! In any case even 200 uF looks like it could work. Go for it!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm curious as to why you need to use 5.5V and not the "usual" 5V. Are you using some adjustable regulator?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee,

X5R ceramic capacitors (the ones with the most capacitance per volume) tend to lose their capacitance with voltage. At 50% of rated voltage, you can expect their capacitance to be about 50% of what the manufacturer claims. At 100% of rated voltage its probably more like 20%. That's why I stated 10V capacitors, 6.3V would be worthless. While I could go with electrolytic or supercapacitors instead it would be tough to get one physically small enough even though they would have more than ample capacitance. Also, ceramic capacitors tend to be more reliable than electrolytics, which would make them my best choice.

The 180 uF was based on a draw of 5 mA, that number was based on the "active current" in the datasheet and may have very little to do with the current under actual operating conditions, hence my original question. It's also worth pointing out, 180 uF was the absolute bare minimum. I'd want at least 30-40% more than that just to take into account tolerances. So it would be more like 250uF, not 200uF if I went that route.

John,

I'm attempting to replace a part in a working circuit. I don't get to pick the voltages involved. It is what it is. The circuit was actually pretty clever. They are supplying voltage to 4 NiCd cells through a 500 ohm resistor and then I believe they essentially diode OR the supplies together. The fact that its running at 5.5V is actually an advantage since it lets me put more charge in the capacitor and hence gives me more time before I run out of voltage.

I dropped some logic analyzer probes on it. It's almost what I expected. There are 10 bytes of memory that get read, and occasionally written to (corresponding to external input). These are bytes that absolutely should be backed up. There is an 11th byte that is frequently read and written to. I have no idea what it does (I wasn't actually probing the data lines). My guess is, this is not critical to backup. There's a 12th byte that is read corresponding to external input. I don't ever see it being written to so it may just be crap the MCU is throwing out on the memory bus (although its interesting that I can recreate it at will). I don't see any read or write access to the remaining 20 bytes. If it really draws 5mA, I should be able to back everything up on 100uF.

The other thing I noticed was that there were some read accesses that lasted for only 600ns (which is shorter than the 700ns max access time of the RAM). I'm wondering if an 8MHz AVR could keep up with that, even if its polling. OTOH, the 600ns accesses may not have been real (like I said, I think there were some reads that were bogus).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should perhaps consider the dedicated (but maybe more pricey) alternatives for this task: FRAM/Ramtron, nvSRAM/Cypress (ex-Simtek, ex-ZMD).

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those were the first things I considered, however I could not find a pin compatible part. If I could find one with a smaller footprint I could deal with pin-incompatibility. However, all of the parallel RAM chips that had NV capability were considerably larger (physically as well as datasize) and physically would not fit. Its sad, because the Cypress parts do EXACTLY what I want, but are physically too large.

The Ramtron/FRAM is not a good option since it has a limited number of read/write cycles. Although EEPROM has far less write cycles, the EEPROM will only get written too very occasionally compared to how often the SRAM will get written to or read from.

I'm not willing to consider a lithium backed SRAM for a variety of reasons.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be great if you could report back what the I-V curve looks like while simply draining the caps for power, comparing writing to EEPROM and not. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hpmaxim wrote:
The Ramtron/FRAM is not a good option since it has a limited number of read/write cycles. Although EEPROM has far less write cycles, the EEPROM will only get written too very occasionally compared to how often the SRAM will get written to or read from.
Last time I looked (which was maybe 5 years ago), the 3V FRAM parts stated "unlimited" access cycles.

Anyway, you still can use a serial FRAM and some tiny microcontroller instead of EEPROM; the write time is several orders of magnitude shorter so you'll trade the capacitor space (and issues) for the external memory (you could also try to position the chips on top of each other, or putting them on a thin PCB mounted in right angle to the original PCB, reducing footprint further if that is desperately needed.) Ramtron makes mcus with embedded FRAM, but the smaller one is TQFP44, and lately also NRND, IIRC.

JW

PS. This made me curious, so I went to Ramtron's web and found http://www.ramtron.com/files/tec...

Quote:

CONCLUSION
The endurance performance of FRAM is
characterized by a mathematical model which
predicts that a 1.0 x 10^16 specification is
appropriate.

One year is 3E7 seconds, so if your application writes to the memory every microsecond (1MHz), it should last some 300 years.

In light of what electronic nowadays means, this is pretty much an infinity...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm getting lost in all the claims and suppositions above. I'm just a simple-minded old bit-pusher. Everything else being equal, I'd work like hell to just use the AVR's EEPROM given that space is a concern--With the onboard EEPROM for parameter storage, and SRAM and common peripheral circuits the AVR gives near-single-chip designs.

That working like hell might include examining why all 32 bytes are needed? And in worst case how many of them have been changed and need to be re-written--very important.

A. So, with your power supply first determine how many bytes you can save. If it comes to 234, then the hand-wringing is for naught. Common sense, right? So set the brownout detector to a reasonable level. Set up your power "trip" in the AVR--logic level, A/D AC, whatever. When you detect a trip, go into a loop and write to an EEPROM location- 1, 2, 3, 4, until the brownout detector stops you. Then read out the number from the EEPROM location using ISP or other. Repeat a few times. Get the average or the worst case or the beat case or whatever turns your crank. You will come up with a simple number such as 123. If you can't give me that simple number with all the calculations and hand-wringing above then I'll continue to ask for it.

B. I usually consider that number "worst case" and feel comfortable at about half that. Not everything needs writing, as mentioned below.

C. Especially if using a spare I/O as the trip trigger, the above is easy to track on a 'scope. If you care to answer the question of how much power is used to write EEPROM then that is the time to do it. I've never really cared--the number from A. is important.

D. Do you really need 32 bytes? Let's say you do.

E. Use CodeVision, or do as it does: only erase and write if the value isn't already there. Typically, that cuts the magic number to a fraction.

F. Let's say these are 8 32-bit values. Have app code that does an EEPROM update when they roll over the high two or three bytes, during normal operation. Then when E. runs there will be >>most<< of the bytes that need no writing.

G. Modern AVRs have erase-only and write-only EEPROM operations. So the area can be pre-erased and save about half the time.

All of the above requires no "coulomb" calculations or other anywhere. It takes the target app board, runs it under real or simulated conditions, and comes up with a simple number: how many bytes can I write? That >>is<< the important thing here. None of the rest (e/.g. capacitance available; power draw during EEPROM operations) matters.

But I'm just old and simple.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tlucas,

Last time I checked dV/dt = I/C. In the case of ceramic capacitors this isn't really the whole story since C will increase as V decreases, so if you derate the capacitor initially that number will be pessimistic, if you don't it will be optimistic. You can look up the X5R voltage coefficient its published.

wek,

Yes, I noticed they had some very high endurance parts. The problem is, 44 pin TQFP is way too large. All of their 5V parts are too large. The serial parts possibly would work but then I'd need an AVR to translate serial to parallel, and it'd have to be a larger AVR because I'd probably need more IO. I think it would turn a hard problem into a harder one. I appreciate the suggestion, its a good one. Like I said, I initially really liked the idea of using a Cyrpess chip. Unfortunately, the 5V chips are physically just too large.

theusch,

As I previously stated, based on observing the SRAM in action, only 12 bytes appear to be used. One or two may be bogus, but the remaining 10 absolutely could be changed and should be saved. Its not likely all 10 would change, but it is possible and I need to be able to handle it. So my goal should be to be able to write 12 bytes. Assuming there are 4 byte pages, there would be 2 full pages, 1 half page, and two spare bytes. If I only need to save 10 bytes it would be 2 pages, plus two spare bytes.

It is my intention to only update the values that need to be updated, but that's for endurance reasons not speed reasons, because if I can't write 12 bytes then the design is inadequate. This also precludes the use of the pre-erase function since I won't know until shut down what needs to be erased.

Regardless, in order to do this I still need to know how to write to the EEPROM so that I'm minimizing my current consumption, and that hasn't really been addressed. Is there a technique I can use to shut down the MCU and then wake it up on an interrupt saying I'm ready to write out the next byte?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hpmaxim wrote:
Last time I checked dV/dt = I/C. In the case of ceramic capacitors this isn't really the whole story since C will increase as V decreases, so if you derate the capacitor initially that number will be pessimistic, if you don't it will be optimistic. You can look up the X5R voltage coefficient its published.
Current will not be constant (writing to EEPROM may show decreasing steps in voltage with each bit written; microcontroller current use decreases with voltage), and you mention capacitance will also not be constant, so nothing is known in that equation. I assume you will be looking at voltage on a scope while this device powers down... would be great to see that image, so we can see how much actual charge goes into various operations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I still need to know how to write to the EEPROM so that I'm minimizing my current consumption, and that hasn't really been addressed.

And >>I<< want to know the number--as I said I would be asking for above.

Yes, the points you make are important, or may seem important to you. But they are moot if the number is 2x or 5x or 8x the number you need.

I gave several ways of minimizing the number. These are indeed important. You haven't even paid lip service to pre-erasing.

Yes, calculations are important. I thought the goal is to race powerdown. You can do 4,000 different equations and analyses and "the number" is of paramount importance--that is how reaching your goal is measured. And it is simple to do, and re-do as the app is adjusted. I'm out; y'all are too sophisticated for me.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch,

Quote:
It is my intention to only update the values that need to be updated, but that's for endurance reasons not speed reasons, because if I can't write 12 bytes then the design is inadequate. This also precludes the use of the pre-erase function since I won't know until shut down what needs to be erased.

I believe I did address your pre-erase issue. You may be right, I may be worrying over nothing. Maybe I have way more time than I think. However, based on every published number I've seen, I'm marginal at best and I'm certainly not 8x. It seems like you are saying go ahead and spend a lot of time and very potentially risk an expensive system, not based on reasonable numbers, but rather inspite of them -- just to satiate your curiosity. Its very frustrating.

tlucas,

You do have a point, the current may vary as a function of voltage. I'm not at all convinced it would go down though. The sense amps probably draw a relatively constant amount of current, the charge pumps probably increase in current as voltage decreases. The thing is though, I don't know how much current that is to begin with, and I don't know if you can reduce the normal 4-5mA nominal current. The problem is I don't really have a readily available test fixture for testing this.

I found an X5R graph and it looks like the capacitance derating would vary linearly from about 35% at 5.5V to about 7% at 2.7V. If we assume those are the limits, its probably okay to just average those numbers and claim that you will get about 78% of the rated capacitance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You may be right, I may be worrying over nothing.

No, I never said that. What I'm trying to say is the SIMPLE FACT is you neeed to write n bytes at powerdown before the BOD kicks in. The question is: How many EEPROM bytes can you erase/write before the BOD kicks in?

That is the number. Without the number, you >>don't know<<, no matter >>how much<< analysis you do, whether you have achieved the goal.

So why not do the simple test, find the number, and see how it compares to the goal?

I've done this on like a dozen apps. Only once that I can recall did I even look back at the schematics, 'cause my number was OK. In one case I turned off more power suckers and then the number was OK. I've never looked at a capacitor graph; the only important thing is can enough bytes be written. >>IF<< not met then perhaps one looks at those things.

Am I being too simplistic? How can you go any farther without knowing the number?

Quote:

I believe I did address your pre-erase issue.

With that above?!? Not. You erase the whole block, and write the whole block. In real life you'd probably have a small array of these blocks, index to active, integrity check, and the like.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a brief glance at the tiny2313 (non-A) datasheet. and there's a graph saying "programming current vs. supply voltage" (parametrized by temperature). While it's not clear whether this is FLASH or EEPROM programming, it may give a hint - the currents are in the order of 2-4mA.

The second issue is core consumption. I believe you can minimise that by putting it into sleep and wake up by timer (or by interrupt on EEPROM programming finished, if this is possible, I did not check). Whether core can sleep during EEPROM programming is not explicitly said in the datasheet but I see no reason why it could not be so.

You might perhaps also ask Atmel's support for more details, if you are reluctant to believe in the results of a few simple experiments Lee and others suggest.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A quick idea came to me today while working outside in the garden :-) : couldn't be storing a dozen of bytes in FLASH be faster/energetically less demanding than the EEPROM thing?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek,

That occurred to me as well. I had originally considered the idea and rejected it on the basis of the limited endurance of the FLASH. However, it seems like since the page size of the 2313A is 32 bytes (which coincidentally is the same size as my SRAM), I could simply use different pages, and then store an index to the page in a single EEPROM location. That reduces the task to one EEPROM write and one FLASH write and still retains the endurance of the EEPROM (in fact, the EEPROM endurance becomes the limiting factor).

I wasn't sure that you could actually write and read FLASH from within the code though. I thought this was essentially only something you could do while programming the part.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek,

After consulting with my coworker he agreed it was impossible to page write the EEPROM, and write to the FLASH at all from within the program space. He also pointed out that most likely the part would not be fast enough at 8MHz to meet specs, so I've gone back to your original idea of using a non-volatile SRAM. He pointed out that there are surface mount headers which puts me under less physical space constraint. Still a physically tighter fit than I'd like, but I think I can make it work.

Thanks again for your excellent suggestions!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

using a non-volatile SRAM

You've heard of Ramtron's FRAM I take it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

He also pointed out that most likely the part would not be fast enough at 8MHz to meet specs,

WHAT specs? You still haven't given me the "number". Let's re-phrase--how long is it from when power loss is detected until the AVR hits the brown-out threshold. All the hand-wringing above, and that has NOT been answered.

You all "agree" that it can't be met. On what basis? Space is important. No sense adding more cost. With external SRAM or FRAM or RTC with SRAM or ... THERE WILL STILL BE A RACE! You still need to know the "number".

IME our apps have ~100ms from impending doom to BOD. Obviously that depends on power-suckers and everything else about the app. A few bytes can comfortably be re-written. And with a pre-erased block as with the new AVRs the write time is roughly halved.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

we've been discussed FRAMs a dozen of posts ago.

Lee,

hpmaxim wrote:
I am attempting to replace a battery backed up (32x8) SRAM in a current design. [...] My entire "device" must fit in an area smaller than a 18 pin DIP.

Although hpmaxim might have been clearer in his specs, I believe this is quite enough for an experienced EE/programmer you are. When replacing a parallel memory by a parallel memory, no processor is needed.

hpmaxim,

incedentally, somebody on a different forum asked for a replacement for an 8253 (Intel's famous triple timer from the MCS-80 suite). I immediately shot out that any contemporary mcu would do, but then had a look at the specs... no way to get the response under the bus cycle requirement (400ns read/write cycles). The way things were done in the past is gone and while we have a replacement for the whole system within a single chip, the individual parts appear not THAT trivial to replace.

But, while at it, let me quote a paragraph from the 8253 datasheet. I would suggest to insert this paragraph as a preamble to the avr-libc's documentation.

Intel 8253 datasheet wrote:

The 8253 solves one of the most common problems in any microcomputer system, the generation of accurate time delays under software control. Instead of setting up timing loops in systems software, the programmer configures the 8253 to match his requirements, initializes one of the counters on the 8253 with the desired quantity, then upon command the 8253 will count out the delay and interrupt the CPU when it has completed its tasks. It is easy to see that the software overhead is minimal and that multiple delays can easily be maintained by assignment of priority levels.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

He also pointed out that most likely the part would not be fast enough at 8MHz to meet specs,

WHAT specs? You still haven't given me the "number". Let's re-phrase--how long is it from when power loss is detected until the AVR hits the brown-out threshold. All the hand-wringing above, and that has NOT been answered.

As I very clearly stated, I'm attempting to emulate an SRAM. Whatever device I use or build or what have you has to meet the maximum specifications of the original SRAM, which includes a maximum access time of 710ns. After trying to write assembly code to actually service read/write requests we determined that it was impossible to meet this on an 8MHz AVR. 20MHz yes, 8MHz no... I don't want to run it at 20MHz because I don't want to have an external crystal and be generating lots of RF inside something that would be particularly sensitive to stray RF particularly near that frequency.

Quote:
You all "agree" that it can't be met. On what basis? Space is important. No sense adding more cost. With external SRAM or FRAM or RTC with SRAM or ... THERE WILL STILL BE A RACE! You still need to know the "number".

The Cypress parts are designed to handle this "race" condition. Their datasheets explicitly provide instructions on dealing with this situation, including the size of external capacitor required in order to guarantee "winning the race." No reason to reinvent the wheel. This is the part I wanted to use initially. It was simply a matter of making it physically fit, which I hadn't thought possible until now.

Quote:
IME our apps have ~100ms from impending doom to BOD. Obviously that depends on power-suckers and everything else about the app. A few bytes can comfortably be re-written. And with a pre-erased block as with the new AVRs the write time is roughly halved.

As an analog IC designer, I can tell you the time from impending doom to BOD has to do with a bazillion factors, and attempting to generalize and say you've got ~100ms (which is *WAY* more than I need) is pretty much silly. Every application is different. In my particular case it depends essentially entirely on the amount of capacitance (which I have some control over) and the amount of current consumption (which I may be able to curtail but don't have a huge amount of control over, nor knowledge of). In terms of pre-erase, I already explained why I disliked the idea of a pre-erase. It guarantees a limited number of power cycles for absolutely no good reason. This technique would also require sensing the "impending doom" as soon as possible and in truth I don't know how quickly I could do that. Obviously, if the BOD trips doom is impending but at that point, its too late.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are much better off detecting power failure on the unregulated input. For instance if you have a 12V supply input with a 5V LDO regulator, then you could set your power fail detect threshold at about 10.5V. Lets also say that the dropout voltage of your 5V LDO is 5.5V. That gives you 5V of overhead before you even drop out of regulation.

You can use the onboard comparator inside the TINY2313 so you don't need any extra parts except resistors to divide the input voltage down to an appropriate level.

Now the numbers.
32 bytes x 3.4mS = 108.8mS
You're going to want a "significant" safety margin (let's say 30%). This gives us a time to live target of about 142mS.
Although you didn't say, let's assume at you are running the micro at 8MHZ at 5.5V. This will give you a core current of about 6mA. Add 4mA of programming current to give you 10mA (assuming that you've turned everything else off after you got the power fail detection.

Let's calculate how much input capacitance that we need.
I = Cdv/dt or C = Idt/dv
C = 10mA x 142mS/5V
C = 284uF (round up to 300uF)

So, 3 x 100uF, 16V tantalum capacitors (6032 case) would work. Of course this analysis assumed many things like a 12V input voltage, 8MHZ core speed, etc. You will have to adjust these numbers based on your system parameters.

Another thing to consider would be to erase the 32 bytes of EEPROM storage area "BEFORE" you have write them again. You can erase them under normal operation conditions while you have power. When you get the power fail, all you have to do is write them. This only takes 1.8mS per byte instead of the 3.4mS Erase/Write cycle time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case all fails, use an external device like ST's M25P20. They need more mA but only 2.7V .

Ooops, they are numonyx now.

Here is the data sheet.

http://www.numonyx.com/Documents/Datasheets/M25P20.pdf

The M25P16 is even faster.

Page Program (up to 256 bytes) in 0.64 ms.

http://www.numonyx.com/Documents...

http://www.numonyx.com/en-US/Mem...

updated with faster unit.