8-bit MicrocontrollersのトピックRe: Managing Burned Out EEPROM segments

Managing Burned Out EEPROM segments

belskyc — Tue, 10 Nov 2009 07:48:44 GMT

Hello,

I have an application using the DZ60A (8-bit uP) that is susceptible to EEPROM cells burning out due to exceeding the lifetime erase/write cycles of the EEPROM. The value (I'll just call is "x" in this example) that I'm storing to EEPROM is 4-bytes, and I'm using the 4-byte mode of EEPROM. Thus, I have created a two-dimensional array in EEPROM sized [100][4] where I can do a "rolling" routine writing "x" to the next arrary cell during every write. This gives me approximately 5-million erase/cycles for "x". My situation now is that I need a method to monitor and save the locations of any array cells that are burnt out. Does anyone have any creative solutions for this type of application?

Thanks in advance,

belskyc

Re: Managing Burned Out EEPROM segments

bigmac — Tue, 10 Nov 2009 10:17:58 GMT

Hello belskyc,

A way to keep track of bad EEPROM blocks might be to simply maintain a separate 100 byte array within either EEPROM or flash, to be written, but never erased.

The more difficult issue might be to sense when a particular EEPROM block has gone bad. One possibility would be to verify the contents of an EEPROM block immediately after a write, and then attempt at least one additional erase/write cycle before marking the block as bad.

However, this would not cater for a failure mode where the corruption of a bit state takes some time to occur after the write process. I do not know enough about the failure mechanism to say whether this is a real possibility. If this case needs to be allowed, you will probably need to maintain two data arrays so, that a comparison can be made prior to making use of the data.

Another factor that will need to be taken into account is the possibility of power loss occuring during the data update process. You would need to ensure that the supply voltage does remain above the LVD level for the whole erase/write cycle (25 ms plus). It is possible that you will need early warning of power loss to the input of the regulator and/or a larger bulk capacitance than usual at the output of the regulator.

Regards,

Mac

Re: Managing Burned Out EEPROM segments

tonyp — Tue, 10 Nov 2009 16:21:54 GMT

bigmac wrote: You would need to ensure that the supply voltage does remain above the LVD level for the whole erase/write cycle (25 ms plus). It is possible that you will need early warning of power loss to the input of the regulator and/or a larger bulk capacitance than usual at the output of the regulator.

And if taking that route, maybe you could change your approach and write to EEPROM only when you're about to lose power. All other times, you keep that data in RAM. That way you minimize total EEPROM writes, in the first place. Just need to make it last long enough for the whole programming duration (e.g., supercapacitors).

I'm hoping some day we'll see MRAM instead of EEPROM.

Re: Managing Burned Out EEPROM segments

tonyp — Tue, 10 Nov 2009 16:37:54 GMT

belskyc wrote: My situation now is that I need a method to monitor and save the locations of any array cells that are burnt out. Does anyone have any creative solutions for this type of application?

I believe EEPROM (at least some types) is burned out at the bit level (not the byte level). If that is indeed so (someone else might know better), you could use 7-bits for data and 1-bit for "bad" flag. You will write the bad flag only once (from one to zero), when you feel the cell has had it. When writing data, you always OR the bad flag bit with 1 to keep it in the erased state. All that assuming the first sentence is valid.

Re: Managing Burned Out EEPROM segments

belskyc — Wed, 18 Nov 2009 03:39:15 GMT

Thanks bigmac and tonyp for all the input. Great suggestions. For this application, I didn't have the luxury of doing a hardware change to implement the LVD to store the critical values during power down, but I'm definitely going to keep this in mind for future applications - good idea. I ended up going the route of creating a 12-byte word where I tracked burnt-out status of each EEPROM byte with a bit & mask in the 12-byte word, thus I was able to track the necessary 96 bytes of EEPROM (I shrank from 100 bytes to 96 to fit the 96 bits). This was a compromise of more complexity to save 100-byte memory to log burnt-out status down to 12-bytes to monitor the same.

Thanks again for the suggestions - all good stuff.

~belskyc