Bad Eeprom write on '628???

[bethr]

Hi:
I am trying to save PORTB pin status on Power On Reset, then when power is restored the data will be the same there is my code:

start:
trisb=0
gosub update ' restore last portb value

mainlop:
portb = portb +1
gosub store_val 'update the value on rb to eeprom
pause 1000
goto mainlop


update:
read 0,last_val
PORTB= last_val
return

store_val:
last_val=portb
write 0,last_val
pause 10
return

is too simple, it means a loop where the portb is incremented once each second and then save the status on eeprom, but it doesn't work !
when I remove the power then I restore, th leds atached to the port b is a number different to the I can remember when the pic is shut off!

Ovbiously I init the eeprom data with a number before taht the pic can run on first time!
What I doing Wrong?
Thanks!

[Jerson]

You should not write to the EEPROM every second. The number of writes is limited if you know. Ideally, if you need to save, you should save only if there is a change in status of the port. This will reduce the number of writes.

This looks like a test program to me. So, please think of your real application. You may not need to update the EEPROM so frequently..

Jerson

[paul borgmeier]

1)You haven't declared last_val

2)If you lose power while writing to the EEPROM your saved value might be corrupt

3)You most likely will shut off power during the pause 1000 – in this case you would not expect to see the same number when you repower up. Say you had PORTB = 28 when the power went down (during the Pause 1000). 28 should be in the EEPROM. When you reapply power, the number 28 is read back and put on PORTB. a few microseconds later you add 1 to that and display the new value, which you see. Therefore 28 !=29.

4)Jerson is right – your eeprom is limited in the number of writes – how about detecting the power loss and writing the value to EEPROM before the power drops out?

5)

Ovbiously I init the eeprom data with a number before taht the pic can run on first time!

Not to me, I don't see it in your code.

[bethr]

Thanks by your comments friends, my real app is simple y try to make a ir (infrared) control box that control 4 relays the only that i need is save the last relays status when a possible reset ocurr!, it ensure that there is no change when the power suply is shut down!

last_val is a byte sized var, and I do not write a statemment as

" WRITE 0,1" ;INIT EEPROM

instead I mod the eeprom data memory in MPlab when i burn the Chips, so
How I can detect a power loss?, what is then the best way to do this type of things?
my idea is save the PORTB status ONLY when a new value is reloaded from a an Ir controller, instead each second as the above code is!.

Thanks Again!

[paul borgmeier]

>> How I can detect a power loss?

Lot of ways to do this ... without a schematic or more detail it is hard to say what is best. For moderately low power projects, I place a fast diode between the power supply and VDD. I also place a cap between VDD and GND. I then monitor the voltage from the anode of the diode (also connected to the PIC through a diode) and sense when it goes low (with ADC or Comparators). When it goes low, I shut off everything and write to EEPROM. I size the cap to give me enough time to do this.

Others might do this differently (like using BOD).

[bethr]

As you can see the schematic is very simple.
I try to make the changes what you say, view the ADDED.jpg file I think that this may work, today I also make code changes and i try again, let know if the the squematics looks like you say,

Thanks

[keithdoxey]

I have given this consideration for a project that I am working on as well.

Realistically how often is the status of the relays going to change ?

How many times per day in total ?

The EEPROM typically has a life of 1 million cycles which can be used up very quickly with frequent updates, or may well outlive everyone on this list if the frequency of updates is quite low.

What is the designed lifespan for your product ?

1 second = 86400 per day = 11.57 days
10 seconds = 8640 per day = 115.7 days
30 seconds = 2880 per day = 347 days
1 minute = 1440 per day = 694 days
5 minutes = 288 per day = 9.5 years
10 minutes = 144 per day = 19.0 years
30 minutes = 48 per day = 57.1 years
1 hour = 24 per day = 114 years
2 hours = 12 per day = 228 years
6 hours = 4 per day = 685 years
12 hours = 2 per day = 1370 years
24 hours = 1 per day = 2740 years

If there are less than 50 updates per day then I wouldnt bother trying to detect power failure as its going to take over 50 years to kil the eeprom, even updating every five minutes will give you the best part of 10 years.

[BobK]

Hi Keith,

Something has been bugging me for several years after reading about the lifetime of an EEPROM. Is the lifetime determined by how many times you write to the EEPROM as a whole or is it per location of the EEPROM? Just curious.

Thanks,

BobK

[keithdoxey]

Hi Keith,

Something has been bugging me for several years after reading about the lifetime of an EEPROM. Is the lifetime determined by how many times you write to the EEPROM as a whole or is it per location of the EEPROM? Just curious.

Thanks,

BobK

Dunno is the short answer.

It might be limited to blocks of memory because I have see mention of moving the location where you store data after x number of writes to get a longer lifetime.

EG 4 times the memory size so you use the first quarter then move the the second quarter etc.

Hopefully someone with more experiece of EEPROM will give a better answer

[Jerson]

The EEPROM typically has a life of 1 million cycles which can be used up very quickly with frequent updates, or may well outlive everyone on this list if the frequency of updates is quite low.

What is the designed lifespan for your product ?

1 second = 86400 per day = 11.57 days
10 seconds = 8640 per day = 115.7 days
30 seconds = 2880 per day = 347 days
1 minute = 1440 per day = 694 days
5 minutes = 288 per day = 9.5 years
10 minutes = 144 per day = 19.0 years
30 minutes = 48 per day = 57.1 years
1 hour = 24 per day = 114 years
2 hours = 12 per day = 228 years
6 hours = 4 per day = 685 years
12 hours = 2 per day = 1370 years
24 hours = 1 per day = 2740 years

Keith

This post of yours is brilliant. You explain very clearly the way the million cycles can be used up and how fast.

Jerson

[skimask]

Keith

This post of yours is brilliant. You explain very clearly the way the million cycles can be used up and how fast.

Jerson

I've done something slightly different, but hey, it works for me...
Got a project (temp/fan controller type thing), controls 4 relays, runs off mains power most of the time, super-low current trickle charger on a battery pack, really small solar cells backing those up...
I save the current relay status about every 10 seconds, 4 bits total. 256 bytes of eeprom. When the unit was first fired up, I cleared all of the eeprom to $ff. The first time I wrote to a byte, I clear bit 7 in byte 0, and saved the status to the lower 4 bits. The next time, I looked for the first byte in the eeprom with bit 7 set, then cleared that byte's bit 7 and saved the status to the lower 4 bits, and so on and so on and so on...
When I get to byte 255, I check the power on the mains (make sure I'm not running off battery backup), then clear all of the bytes back to $ff and start the process over again.
If main power fails, then comes back on, I look for the last byte in the eeprom with bit 7 cleared and read the state from it...then resave it of course...
This way, I use each of the bytes equally (by looking for the first byte with bit 7 set) and saving the state there. According to the table above, I should get about 40 years or so out of this controller. The building will fall down before that!
Then again, there's a thousand different ways to do 'wear levelling' with eeprom/flash and as stated earlier...a guy generally doesn't have to worry about it. I've got an article somewhere that talks all about wearing out eeprom/flash and according to this article, the key is to keep the voltage as low as possible and write as slow as possible (up to the point of doing multiple rewrites at marginal voltage) for maximum eeprom life...and temperature has a lot to do with lifespan. The article also went on to say that even after an eeprom cell has failed during normal writing procedures, rewriting the same cell a few times (within reason of course) will usually work just fine.

I wonder how many of us have actually worn out the flash in a PIC yet...if any...? I thought I did once, turned out the regulator on the MCLR pin went south for the winter (and the rest of the year for that matter)...

[paul borgmeier]

view the ADDED.jpg

Your “ADDED” schematic shows a 16F84A, which has no analog features – if you are using this PIC, you will need to use an external comparator (or something else) to detect the dropping voltage. On the plus side, the 84A has a 10,000,000 EEPROM Write endurance, which is 10X that of the 16F628. This means you can 10X the numbers Keith has in post 7. Also keep in mind these numbers are theoretical and not guaranteed (but in many cases, way conservative).

If you are using the F628, the only change I have on my schematic is another diode between the anode and the analog pin. This ensures the the analog input voltage is the same as VDD and not higher (which would be out of spec).

The best thing to do would be to skip the power detect and do as Jerson suggested (and not record every second but only when a change was detected). If the estimated number of changes is not too many (see Keith's post 7 for numbers), then you are set. If it is too many, you have another option. You can, in software, set up a “wear leveling” approach (as SKIMASK just noted while I was writing this) and use all locations of the EEPROM. This would give you a theoretical endurance of 127 million writes for the 628 and 630 million for the 84A. Some PICs require refreshing of all the EEPROM after a certain number of writes to any location in EEPROM (e.g., 1 Million writes) – check your datasheet. You can extend this approach by using and external EEPROM and have Trillions+ of writes.

Good Luck