Internal eeprom life problem ! * HELP *

[Darren Logan]

Hi all,

I have a bit of a problem I should have addressed earlier in the dev. process but alas I didnt, purely because I forgot!

My application (using PIC16F870) needs to write to eeprom as frequently as every minute!.
Now then, if I only have 100000 write cycles thats only a measly 69 days of cont. operation before possible eeprom write problems yes?!

I have 2 possible solutions:

1. Move the particular eeprom address every say 60 days to another location, but I don't like this idea because there aren't many locations left to play with.

2. Write to eeprom only when the PIC is turned off (or is in the process of being turned off).
This is the best idea, but I am wondering how I can do it???
Maybe I could use a large storage capacitor to hold the power rail high long enough for the PIC to write to eeprom before the power dies to nothing. But this would be a problem because I have LEDs and relays etc. drawing a fair amount of current which would quickly sink away the stored voltage.

Question:
Can I write to eeprom when the internal brown-out is detected? (do I have enough time at 4MHz?)

Any other life saving suggestions?

Waiting with baited breath for your ingenious suggestions!

8-)

Vbr,
Darren
___________________________
This message was ported from CCS's old forum
Original Post ID: 13369

[Sherpa Doug]

1) Would it help if you check if the data has changed before you write it to EEPROM. If the data rarely changes this might work.
2) Power all the big loads off one supply. Run the PIC and EEPROM off a secondary supply, maybe regulated from the first supply. Have the PIC monitor the first supply. When it falters write to EEPROM before the secondary supply fails.
3) Use something other than EEPROM like battery backed SRAM or those ferroelectric RAMs people have mentioned on this board.

Sherpa Doug

:=Hi all,
:=
:=I have a bit of a problem I should have addressed earlier in the dev. process but alas I didnt, purely because I forgot!
:=
:=My application (using PIC16F870) needs to write to eeprom as frequently as every minute!.
:=Now then, if I only have 100000 write cycles thats only a measly 69 days of cont. operation before possible eeprom write problems yes?!
:=
:=I have 2 possible solutions:
:=
:=1. Move the particular eeprom address every say 60 days to another location, but I don't like this idea because there aren't many locations left to play with.
:=
:=2. Write to eeprom only when the PIC is turned off (or is in the process of being turned off).
:=This is the best idea, but I am wondering how I can do it???
:=Maybe I could use a large storage capacitor to hold the power rail high long enough for the PIC to write to eeprom before the power dies to nothing. But this would be a problem because I have LEDs and relays etc. drawing a fair amount of current which would quickly sink away the stored voltage.
:=
:=Question:
:=Can I write to eeprom when the internal brown-out is detected? (do I have enough time at 4MHz?)
:=
:=Any other life saving suggestions?
:=
:=Waiting with baited breath for your ingenious suggestions!
:=
:=8-)
:=
:=Vbr,
:=Darren
___________________________
This message was ported from CCS's old forum
Original Post ID: 13371

[John P]

:=2. Write to eeprom only when the PIC is turned off (or is in the process of being turned off).
:=This is the best idea, but I am wondering how I can do it???
:=Maybe I could use a large storage capacitor to hold the power rail high long enough for the PIC to write to eeprom before the power dies to nothing. But this would be a problem because I have LEDs and relays etc. drawing a fair amount of current which would quickly sink away the stored voltage.
:=
:=Darren

My suggestion is to couple the incoming (pre-voltage-regulator) power to a comparator (or one of the PIC's A/D converters, appropriately level-shifted) and when it goes low, trigger the "save" routine. How this can work depends on how long the processor stays operational after the power-down event begins: you might need an interrupt, or you might get away with polling it every few milliseconds. Also, you might need to turn off all your relays, LEDs etc in order to keep your processor running longer. A lot depends on exactly what you have running and the characteristics of the power supply.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13372

[Darren Logan]

Hello,

Sorry forgot to mention I do not have any i/o lines spare to connect to external prom, so it must remain with internal eeprom.

Looks like I will have to monitor the pre-regulated supply, and as you say provide isolated storage for the PIC.
Uggghhh!, just when I thought the project was finished.

a!!*&(^&shdsjhw***sahf*&$"$£!(*dhdksh)(*&(*&(*^(*&&

... ok that's the swearing over with!

Thanks.
Vbr,
Darren
___________________________
This message was ported from CCS's old forum
Original Post ID: 13373

[John P]

:=:=Maybe I could use a large storage capacitor to hold the power rail high long enough for the PIC to write to eeprom before the power dies to nothing.

One other point--a large capacitor on the 5V side of the power supply gains you very little. It only delivers charge as its voltage drops, so you'll hit brownout while it's still mostly full. You want a big capacitor on the input side of the regulator, so you stay alive as long as it's got enough headroom above 5V to keep the regulator running.

___________________________
This message was ported from CCS's old forum
Original Post ID: 13375

[R.J.Hamlett]

:=Hi all,
:=
:=I have a bit of a problem I should have addressed earlier in the dev. process but alas I didnt, purely because I forgot!
:=
:=My application (using PIC16F870) needs to write to eeprom as frequently as every minute!.
:=Now then, if I only have 100000 write cycles thats only a measly 69 days of cont. operation before possible eeprom write problems yes?!
:=
:=I have 2 possible solutions:
:=
:=1. Move the particular eeprom address every say 60 days to another location, but I don't like this idea because there aren't many locations left to play with.
:=
:=2. Write to eeprom only when the PIC is turned off (or is in the process of being turned off).
:=This is the best idea, but I am wondering how I can do it???
:=Maybe I could use a large storage capacitor to hold the power rail high long enough for the PIC to write to eeprom before the power dies to nothing. But this would be a problem because I have LEDs and relays etc. drawing a fair amount of current which would quickly sink away the stored voltage.
:=
:=Question:
:=Can I write to eeprom when the internal brown-out is detected? (do I have enough time at 4MHz?)
:=
:=Any other life saving suggestions?
:=
:=Waiting with baited breath for your ingenious suggestions!
:=
:=8-)
:=
:=Vbr,
:=Darren
I did a counting system on a large industrial printing machine, that had a similar problem. In this case the count had to be maintained accurately, and could be changing at very high rates. In two versions of the board, I used two different solutions. Both worked fine.
The first was to stop writing to the EEPROM at all. Instead I added a tiny lithium battery to power the PIC, and a voltage detector on the incoming supply before the supply regulator. When the incoming rail fell below 8v, the PIC was put to sleep, and then (with a 0.4v hysteresis), the chip was woken when the supply rose. Asleep, the battery life was years, allowing the required values to be simply stored in the RAM. A MAX690, was used as the supply detector.
The second, used the same detector, but instead wrote to the EEPROM. In this case the hysteresis was set higher, and a system of 'flagged writes' was used. With this, I arranged a byte containing a flag to say that an increment was due, but had not been completed on the higher counter bytes, which is set, when one becomes due, and is then followed by actually writing the bytes into one of two copies. Then the flag is cleared, and the second copy written. On power fail, only the LSB then needs to be updated. If when power is restored, the flag is set, the 'unchanged' copy can be read, incremented, and written to the first copy, and then the flag cleared, and the second copy written. I used this approach, since the counter in this case is eight bytes long, and I wanted to ensure that I only needed (at worse) to write three bytes, given the time available once a power fail was detected. The routine called by the power fail signal, will write the flag if it is pending, and the low two bytes, but nothing else. Given that the upper data is only changed on each 65536 counts, and the lower data, when the power fails, the life becomes acceptable at well over a year (65536 counts, was about 15 minutes).

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13377

[Ron]

Interesting point (eeprom endurance). Hadn't taken that into account until now!

Does anybody understand what is meant by the array refresh Microchip is mentioning in the 18f452 datasheet, sec. 6.8?

They say one one hand that if you don't use frequently changing values, it's required and on the other hand that when EEPROM is only used for data that changes rarely, it's likely not required????

So, it's never required??

Best regards,
Ron

:=Hello,
:=
:=Sorry forgot to mention I do not have any i/o lines spare to connect to external prom, so it must remain with internal eeprom.
:=
:=Looks like I will have to monitor the pre-regulated supply, and as you say provide isolated storage for the PIC.
:=Uggghhh!, just when I thought the project was finished.
:=
:=a!!*&(^&shdsjhw***sahf*&$"$£!(*dhdksh)(*&(*&(*^(*&&
:=
:=... ok that's the swearing over with!
:=
:=Thanks.
:=Vbr,
:=Darren
___________________________
This message was ported from CCS's old forum
Original Post ID: 13393

[R.J.Hamlett]

:=Hello,
:=
:=Sorry forgot to mention I do not have any i/o lines spare to connect to external prom, so it must remain with internal eeprom.
:=
:=Looks like I will have to monitor the pre-regulated supply, and as you say provide isolated storage for the PIC.
:=Uggghhh!, just when I thought the project was finished.
:=
:=a!!*&(^&shdsjhw***sahf*&$"$£!(*dhdksh)(*&(*&(*^(*&&
:=
:=... ok that's the swearing over with!
:=
:=Thanks.
Worth 'sitting down', and doing some calculations of the hold times needed.
For example, on my system, with in the end five writes needed, the 'write time' per byte, is specified as 4mSec (note it is quicker to the program memory, than the EEPROM). The incoming supply detector was built to switch at 9v, and I used an LDO regulator, that could maintain the processor supply down to about 5.3v in. The incoming supply had a 470uF capacitor, and feeds a couple of other pieces of circuitry, drawing about 30mA, with the PIC and regulator together, drawing about 25mA, 'worst case'. On the power fail interrupt, my first action, is to switch off the other circuitry. So ignoring things like the internal resistance of the cap (which will make things slightly worse), and the discharge that takes place in the time period between detection, and switching off the other devices, the simple 'time' calculation, becomes:
T = C * (V/i)
Giving = 470E-6 * ((9-5.3)/0.025) = 0.069 seconds.
If you then allow for the other factors (and take the worst case on things like the capacitor value), this gives me about 0.04 seconds guaranteed, and a time needed of about 0.016 seconds (plus the latency, which in the 'worst case', I took as another mSec).
With some figures for how much data you need to write, the consumption of your unit, capacitor sizes, and the possible points at which you can detect the power, you should be able to get a better idea of how things will 'hold up'. :-)

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13396

[mcafzap]

You might also obtain a slightly longer time by detecting the failure of the AC input to the bridge (if you have one, of course). One other possible course is to use a 'super cap', but beware of current consumption in this case.

Steve
___________________________
This message was ported from CCS's old forum
Original Post ID: 13397

[R.J.Hamlett]

:=Interesting point (eeprom endurance). Hadn't taken that into account until now!
:=
:=Does anybody understand what is meant by the array refresh Microchip is mentioning in the 18f452 datasheet, sec. 6.8?
:=
:=They say one one hand that if you don't use frequently changing values, it's required and on the other hand that when EEPROM is only used for data that changes rarely, it's likely not required????
:=
:=So, it's never required??
:=
:=Best regards,
:=Ron
If it is what I think it is, then for values that have enough writes to exceed 1/10th the cell endurance, they recommend you 'refresh' the values at intervals. However if writes are sufficiently frequent that the figure is this high, the access is probably frequent enough, that this is not needed!.
The key is that the requirement exists, if you have a few cells being frequently written, and others that are not. Otherwise, the need to refresh doesn't exist.

Best Wishes

:=:=Hello,
:=:=
:=:=Sorry forgot to mention I do not have any i/o lines spare to connect to external prom, so it must remain with internal eeprom.
:=:=
:=:=Looks like I will have to monitor the pre-regulated supply, and as you say provide isolated storage for the PIC.
:=:=Uggghhh!, just when I thought the project was finished.
:=:=
:=:=a!!*&(^&shdsjhw***sahf*&$"$£!(*dhdksh)(*&(*&(*^(*&&
:=:=
:=:=... ok that's the swearing over with!
:=:=
:=:=Thanks.
:=:=Vbr,
:=:=Darren
___________________________
This message was ported from CCS's old forum
Original Post ID: 13398

[J Purbrick]

:=Worth 'sitting down', and doing some calculations of the hold times needed.

(Extensive calculation and design analysis follows...)

:=Best Wishes

That's exactly what you have to do.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13423