What is the EEPROM's "READ ONLY" life span limit? - Page 1
Forum section: electronics / beginners

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 18, 2016, 03:16:02 pm
content: EEPROM has a write/erase cycle limit spec in the datasheet. for atTiny's EEPROM its 100K cycle... is this spec applied to when we are "READING" the EEPROM only. i have a situation where i will write the EEPROM content once during programming, but in the running firmware, it will READ the EEPROM content so many times in a second... will the EEPROM die quick this way? i have a hard time finding the READ ONLY spec in the net, all are talking about in combination of either write/erase, or read/write. i know about the WRITE limit, but what about the READ ONLY? i can load the EEPROM content to SRAM during boot once to be safe, and read from that "fixed value" SRAM content many times, but i need to cram every possible SRAM bits for other purpose storing "ever changing" so many variables, loading a fixed valued EEPROM content into SRAM may crippled on how many "quickly changing value" variables in my firmware, so this way is a no (bad) go. i want to make sure that this READ EEPROM many times a second is a safe bet. i need the answer quick, hopefully since i'm coding in this very minute, so please help, may peace be upon you thanks.

author: FreddyVictor
author_rank: Regular Contributor
timestamp: May 18, 2016, 03:21:22 pm
content: The limit is for writing, you can read as many times as you want.

author: Kjelt
author_rank: Super Contributor
timestamp: May 18, 2016, 04:31:30 pm
content: Look at "data retention time" usually this is a graph or table that decreases with overall temperature but for modern components is something from 30 to 100 years, so not much to worry about

author: asgard20032
author_rank: Regular Contributor
timestamp: May 18, 2016, 05:27:33 pm
content: But what would be the lifetime of OTP that they used back in 1985-2004? Does all those gameboy cartridge and nes cartridge will expire soon?

author: Gyro
author_rank: Super Contributor
timestamp: May 18, 2016, 05:36:33 pm
content: It would depend whether they are actually OTP (EPROM dies in plastic DIP packages) or Mask ROM. Mask ROMs are hard programmed in the metalization mask. OTP EPROMs would have a similar lifespan to UV EPROMS, 20yrs+ ?

author: Photon939
author_rank: Regular Contributor
timestamp: May 18, 2016, 05:42:43 pm
content: Quote from: asgard20032 on May 18, 2016, 05:27:33 pmGame cartridges use a different technology called a mask rom. They have a theoretically indefinite data retention time. Now the SRAMs with coin cells? Those can die pretty quick. I have gameboy games with batteries that are already dead but those games had an RTC chip in the cart that ate most of the battery power. Games that just have a battery backed SRAM for game saves are still fine. Even NES carts are usually still good.

author: helius
author_rank: Super Contributor
timestamp: May 18, 2016, 05:51:37 pm
content: Mask ROMs can sometimes degrade depending on the fabrication parameters. The key process is metal migration.

author: Photon939
author_rank: Regular Contributor
timestamp: May 18, 2016, 06:01:00 pm
content: Quote from: helius on May 18, 2016, 05:51:37 pmGot any data on electromigration? I know it is more of an issue for modern processes where dealing with fairly small quantities of individual atoms but would electromigration be a significant effect on such massive lithography processes? Intel is down in the <20nm area but my laptop from ~2005 was built on 130nm transistors. NES carts are probably an order of magnitude or two larger still.

author: Cerebus
author_rank: Super Contributor
timestamp: May 19, 2016, 06:30:26 pm
content: Quote from: Gyro on May 18, 2016, 05:36:33 pmThe rated retention period has increased for OTP PROMs as time has passed. Early OTPs had a 10 year retention spec. in the datasheets a decade later is was 20 years, and now we have parts with 30+ year retention specs. Whether this is a real increase in retention life or a result of better data on retention times is a question I'd like answered. What I mean, if it isn't immediately clear, is that did they hedge their bets at 10 years based on accelerated ageing tests and extended the lifetime spec as older parts proved more reliable or did actual process improvements lead to longer retention times? That is, are those old parts with a nominal 10 year life still working at 30-40 years on, or have they died.

author: Kjelt
author_rank: Super Contributor
timestamp: May 19, 2016, 10:09:01 pm
content: If the OTP rom has the same technology as the eprom but without the glass you could also do the same trick as with an eprom, read and re(over)write, the existing charge would be refreshed as new and the lifetime is again 20 yrs.

author: alank2
author_rank: Super Contributor
timestamp: May 19, 2016, 10:15:21 pm
content: Our of curiosity to the OP's question - why read and reread EEPROM again and again? Once you have started up and load load it into SRAM, what is the point?

author: Cerebus
author_rank: Super Contributor
timestamp: May 19, 2016, 10:28:40 pm
content: Quote from: alank2 on May 19, 2016, 10:15:21 pmA lot of microcontrollers run code directly out ofxROM, for varying values ofx.

author: SL4P
author_rank: Super Contributor
timestamp: May 19, 2016, 10:29:04 pm
content: Quote from: alank2 on May 19, 2016, 10:15:21 pmPerhaps to reduce the amount of SRAM being used? I.e. only transiting as a buffer...

author: Paul Moir
author_rank: Frequent Contributor
timestamp: May 19, 2016, 10:32:03 pm
content: For example, the Attiny13a has as much EEPROM as SRAM (64 bytes). Doesn't leave you with much.

author: uncle_bob
author_rank: Unknown
timestamp: May 20, 2016, 01:34:43 am
content: Quote from: helius on May 18, 2016, 05:51:37 pmHiEarly mask ROM's had a number of issues. Each manufacturer had their own issues. Some of the ROM's started to die within a year of manufacture. There are a lot of older instruments that are going belly up because the EPROM's, mask ROM, and Flash have started to hit the wall. Since most of the parts are in the "out of production long ago" category ... fixing them can be a chore. Best bet: backup everything now.Bob

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 20, 2016, 04:12:14 pm
content: Quote from: alank2 on May 19, 2016, 10:15:21 pmas other have mentioned, attiny13a only has 64 bytes of SRAM. if i store eeprom value in sram during load, then i have less sram space left. there is a 4 bytes constant stored in eeprom, if i load it into sram, i have 60 bytes sram left = 30 words (2 bytes each) variables can be stored. if i read and reread from eeprom each time, i can store 32 words variables in the sram, extra 2 variables which is better. this is a matter of pushing the mcu to the limit by using resources wisely, if it even a wise decision to make, hence i ask in this thread.otoh, before somebody come up with a suggestion "buy bigger mcu"... not a good option since i'll need to source money to buy new stocks and then leaving my 40++ qty attiny13a unused. and i'm not aware of bigger atmel or pic mcu in 8 pins SOIC or 6 pins SOT-23 package (i have pic10f206 as well), these micro mcus are fun to program albeit the limitation. the fact that they can do plethora of things than a bigger NE555 with far less BOM is one of the wonder of the world, imho...

author: alank2
author_rank: Super Contributor
timestamp: May 20, 2016, 04:45:06 pm
content: Quote from: Mechatrommer on May 20, 2016, 04:12:14 pmIt was a good question - I understand the resources (sram) are low and you can take advantage of reading from EEPROM whenever you need to. I even heard of people using EEPROM to store bytes that won't fit in flash too.This is timely for me - I'm working on some new AVR library code that allows you to load/save an entire structure of X bytes to EEPROM with wear leveling.

author: Yansi
author_rank: Super Contributor
timestamp: May 20, 2016, 04:57:55 pm
content: Quote from: Paul Moir on May 19, 2016, 10:32:03 pmtiny13 is an old heap of overpriced er... something one should never use into new designs these days.

author: uncle_bob
author_rank: Unknown
timestamp: May 20, 2016, 05:07:04 pm
content: Quote from: Yansi on May 20, 2016, 04:57:55 pmHiNo more overpriced than a lot of (essentially obsolete) parts from that era. There are designs that people try to keep going for decades. Simply being able to *get* parts at all (regardless of price) is a "really good thing". The cost is passed on to the customer and it all works out.Bob

author: Yansi
author_rank: Super Contributor
timestamp: May 20, 2016, 05:16:14 pm
content: Sure...BTW, I have just looked and the prices of these atmel micros dropped drastically. It's been quite a while (few years?) since I quit using atmel MCUs and switched to STM8 / STM32. When I saw the tiny13 last time, it cost something like 2-3$ here in single quantities.

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 20, 2016, 05:31:24 pm
content: Quote from: Yansi on May 20, 2016, 04:57:55 pmsuggestion please? same footprintQuote from: Yansi on May 20, 2016, 05:16:14 pmbuy lots.. not so lots just say 10 qty...http://www.ebay.com.my/itm/10PCS-ATTINY13A-SU-SOP8-IC-MCU-8BIT-1KB-FLASH-NEW-/171759402808?hash=item27fda87f38:g:i0EAAOSwstxVMyUTso this is not so bad, compare to say, NE555 and other passives that i need to buy separately from different suppliers as well? the price will be an issue if you are producing thousands of a product, but me its mainly hobby.. and the fact that the price dropped maybe they want to push it back into the market?i havent figured out the promising and cheapest way to program arm chip. i downloaded many arm ide, they are not as good and as convinient as AVR Studio 4 and MPLAB 8. and Segger is crippling my clone programmer, the original cost many hundreds, the EDU version i have a feeling is crippled in someway as well (you cant use it in production), the Keil uVision appealled to me (after downloading crippled version from their site) the cheapest option for me, its nearly $2K, its just nuts. and as i mentioned, i'm yet to see arm chip in SOIC 8 or SOT-32 6 package, all are big tarantula's that is impossible to fit in say a 1cm x 1cm board.

author: uncle_bob
author_rank: Unknown
timestamp: May 20, 2016, 05:38:05 pm
content: Quote from: Mechatrommer on May 20, 2016, 05:31:24 pmHiThe simple answer on programming an ARM at the hobby level is generally a $15 demo board with built in programmer. The ones I have seen have an un-populated socket on the board for just that purpose. When you do your project, you populate the location on the programmer and that does the trick. That said, my ten year old J-Links are doing just fine with the latest and greatest drivers. Nothing crippled about them.Don't even get me started on MPLAB vs the free stuff on ARM. Unless you have actually used both to go through an entire project, you haven't seen just how far ahead the ARM setup is. I've done a *lot* of work under both.Bob

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 20, 2016, 06:03:46 pm
content: Quote from: uncle_bob on May 20, 2016, 05:38:05 pmthanks for the suggestion, i'll google when the time comes, but i've done this in few times before, the latest is few weeks ago for me to decide which ide i'm going to learn and put in my freshly formatted PC, i decided the crippled keil uVision, i cant be too carefull and i cant learn all of them either. but so far, arm option hasnt change my stand. mplab and avr studio is $0 cost, non crippled assembly capable suitable for small mcus like this... but they are older version, the newer version i got informed are netbean based and buggy suck arse so i dont bother, older version support my chips thats all i care.. maybe our different stand on this is due to lack of information available on my side. the decision for crippled uVIsion was mainly due to dannyf's blog, he showed some basic step by step... but i still find it not so complete. i know many netbean based are free but i'm not comfy with the performance and features. maybe you can make a blog the easiest and cheapest step by step on arm programming from monitor to flash and add it to the collection of internet knowledge based? tell me, i will be looking forward to it.. since you mentioned your j-link.. i guess its a clone too. the segger driver ver 5 wont let you, ver 4.44 started to give warning, i only can use up to driver 4.42 try it if you havent. if you have, maybe your 10yrs old clone is not charted by them, or simply somehow a legit unit. mine is around 5 year old, in the shelf all the time, dont know when it will see fresh light again. few weeks ago i tried boom the driver says "you cannot use clone with this sw" or some sh*t like that, so hack was in order. now its working again, with an older driver version. learning is on the go, dont know when. in the mean time i keep programming avr, easy. so thats my sad story if you are interested to read.

author: uncle_bob
author_rank: Unknown
timestamp: May 20, 2016, 06:48:08 pm
content: Quote from: Mechatrommer on May 20, 2016, 06:03:46 pmHiThe *only* reason to look at Keil is that it's a great compiler. Every vendor I have ever seen provides a totally free, completely functional, in no way crippled tool chain for their parts. This also includes odd bits and pieces like a free RTOS integrated in the tool chain along with a TCP-IP stack. That bit only works on the "expensive" $4 parts that include built in ethernet i/o (the mac side, but not the $2 phy). Below that you get USB stack support. The sub 50 cent parts don't generally come with Ethernet or USB, there the buffered serial i/o comes in handy.Bob

author: danadak
author_rank: Super Contributor
timestamp: May 21, 2016, 12:51:15 am
content: Another technique to increasing FLASH, EEPROM life is to implement wear levelingin code. Basically keep a counter in flash of the # times you have done writes, andchange the address and reset the counter when you get to the limit. In fact if a UPdoes not have EEPROM, you can make program FLASH look like EEPROM thru thistechnique.Just google "wear leveling microprocessor", lots of hits.Regards, Dana.

author: Yansi
author_rank: Super Contributor
timestamp: May 21, 2016, 12:40:56 pm
content: Freeware ARM toolchains may be far ahead of MPLAB turd, but still I consider many freeware ARM toolchains useless crap - due to mostly their crap debug support. And hell NO, I will not debug a 200MHz cortex M7 peripherals by manually counting bits into 8digit hex numbers, bcs the damn toolchain does not support SVD files fully.For advanced debug, there comes those professional toolchains like Keil MDK ARM, IAR Workbench, maybe Atolic Truestudio,...BTW, Keil is free up to 32kB of code, and STM32F0 (Cortex M0 line) should be completely without restrictions in Keil, as ST has already pre-payed the license for you.EDIT: It is also for STM32L0 product line, here:http://www2.keil.com/stmicroelectronics-stm32/mdk

author: uncle_bob
author_rank: Unknown
timestamp: May 21, 2016, 12:46:21 pm
content: Quote from: Yansi on May 21, 2016, 12:40:56 pmHiCompared to the non-existant debug support in all the other free toolchains, ARM is doing fine in that respect. That said, yes, there are a *lot* of reasons to use Keil. Debug and profiling are two big ones. It's not cheap to get the full setup, but if you are doing this for a living, it's probably worth it. Less time spent completing the project and more time spent at the beach.....Bob

author: Kjelt
author_rank: Super Contributor
timestamp: May 21, 2016, 01:42:26 pm
content: Quote from: Yansi on May 21, 2016, 12:40:56 pmwhich is pretty useless unless you're using cortex m0 instead of an 8 bit uC.Keil or IAR should sell a decently priced license to non-commercial users, instead IAR offers you a whopping 10% discountmissing the point completely.

author: Yansi
author_rank: Super Contributor
timestamp: May 21, 2016, 02:57:43 pm
content: There is still the possibility to use some medication...

author: Kilrah
author_rank: Unknown
timestamp: May 21, 2016, 04:10:47 pm
content: Quote from: Mechatrommer on May 20, 2016, 04:12:14 pmThe PIC12F series has quite a few nice parts.http://www.microchip.com/wwwproducts/en/PIC12F1840

author: uncle_bob
author_rank: Unknown
timestamp: May 21, 2016, 09:10:14 pm
content: Quote from: Kjelt on May 21, 2016, 01:42:26 pmHiThere are indeed work arounds for that limitation. They become a bit impractical once you go above about 256M of flash.Bob

author: Raj
author_rank: Frequent Contributor
timestamp: May 22, 2016, 03:28:54 pm
content: why don't you implement eeprom checksum change detection code? that might help you get less nervous while using eeprom

author: uncle_bob
author_rank: Unknown
timestamp: May 22, 2016, 03:35:58 pm
content: Quote from: Raj on May 22, 2016, 03:28:54 pmHiThe thing I've run into doing that is the wear on the check sum bytes. Whenever a bit is changed in the block, the whole checksum for that block also gets re-done. You either do a check sum per "erase page" (with CRC to correct) and have a lot of space in check bits or you have a lot of wear on a central CRC location.Bob

author: Raj
author_rank: Frequent Contributor
timestamp: May 22, 2016, 03:52:03 pm
content: Quote from: uncle_bob on May 22, 2016, 03:35:58 pmignore the addresses that gets changed often or make them external, like battery backed up ram, or sd card or eeprom on zif slotthe idea is to check whether there is faliure in important addresses, if there is, output error

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 22, 2016, 05:00:13 pm
content: Quote from: Raj on May 22, 2016, 03:52:03 pmmeaning the device is end of life, hence buy new, back to square one... it can be usefull for functional integrity but doesnt do anything with the device's longevity. wear levelling or other different technique may be used for longevity purpose. like a simpler method of a write counter, along with the real data. shift to next location for saving, when the counter is reached. i believe it has been mentioned earlier... both methods of integrity and longevity may be used if one is paranoia about the longevity or service life of a particular device.

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 22, 2016, 05:09:40 pm
content: but even without those contingency techniques, we may take an educated guess of how long a device will be in operational. say worst case write to eeprom (save user settings) will take place 10 times a day. so (100K / 10) = 10 Kdays before the device failed, thats (10K / 365) = 27 years, quite alot compared to most devices life, professional or unprofessional devices... and that assumed you constantly boot up and close down your device 10 times a day the whole 27 years including weekend. i believe 27 years or more can be a realistic figure. with wear levelling technique, we may extend that to say 10X? = 270 years, not something even the biggest company may put their bet on, considering cash flow cycle they need in order to survive...

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2016, 06:49:47 pm
content: If anyone wants to use/take a look at the code I just finished. Some of it has been tested extensively, others like structure.c are hot off the press and barely tested and probably still up for more optimization. The only rule is that you must call StructureLoad() to setup some pointers before calling StructureSave(), but then you can call StructureSave over and over again to keep updating.This does not deal with a single variable in EEPROM being read or written, but a group of variables in a structure. It protects them with a crc16 and does wear leveling on them automatically. It also does mirroring so it has two structures to recover from if necessary.Even if you don't want the structure load/save code, you will find AVR tiny/mega eeprom functions that wear each location minimally as well as i2c implementations that use the tiny/mega twi peripheral or i2c bitbang. Let me know if you have any questions or see any bugs.

author: Kjelt
author_rank: Super Contributor
timestamp: May 22, 2016, 07:36:12 pm
content: Just for the young players:With wear leveling you should read the datasheet a couple of times.There are devices out there where if you write one byte location the whole page is updated, ergo the wearleveling should be done on a per page basis.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2016, 08:05:17 pm
content: Quote from: Kjelt on May 22, 2016, 07:36:12 pmThis is good advice, the ST Micro eeprom's I like to use have a 4 byte "block" that has ECC protection, so if you change one byte, the entire 4 byte block has to be rewritten.The 64K ones also have a 128 byte page write size so you can write 128 bytes during a single write cycle - my code above will handle that transparently. If you cross a page, it will stop the i2c transaction, wait for the write cycle, and then start a new i2c transaction in the new write page.