Go Down

Topic: Extending EEPROM life (Read 2010 times) previous topic - next topic

septillion

Last bit might be true but that's as true for the linked EEPROM... You just have more cycles which is easy to do on a AVR as well by sacrificing more bytes.
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

krupski

May I ask what the benefit of cooking the cells longer is? Is it like sous-vide? :D
Well, in my experience with the Motorola 68HC11, I consistently found that the factory recommended programming time of 10 milliseconds was too short (it resulted - sometimes - in incomplete programming... a few bits were still high that were supposed to be low) and that "cooking" the eeprom with 20 milliseconds resulted in 100% reliable programming.

And, thinking about it, programming a byte involved placing the bit pattern into the register, then enabling the "high voltage" to allow electrons to tunnel through the insulated gates of the individual cells.  Once the charge had been transferred, I assume that no more programming current flows.

As an analogy, think of applying a voltage to a discharged capacitor. Initially, current will flow as the capacitor is charged, but ultimately the current flow will drop to zero (ignoring the real world factors such as leakage, etc).  Leaving the voltage source connected to the capacitor for a longer period will not result in any change.  However, remove the voltage source BEFORE the capacitor is fully charged and you end up with an unreliable programming (thinking of the capacitor as an EEPROM cell)..

I know that leaving the programming voltage on too long degrades the insulating layer and ultimately results in shortening the integrity (storage lifetime) of the eeprom data (indeed this is the wearout mechanism that causes eeprom to be rated for "X" number of programming cycles), but the effects are so small as to be non-existent.

Once years ago I took a "sacrificial" 68HC11 and wrote a small loop that erased a cell, then programmed it to 0x00, then erased it again ad-infinitum.  I let it run for several months and when I couldn't stand waiting any longer, I tested it. The eeprom location programmed fine (although I don't know if it would STAY programmed for the factory specified 10 years).......  :)

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

aarg

Well, in my experience with the Motorola 68HC11, I consistently found that the factory recommended programming time of 10 milliseconds was too short (it resulted - sometimes - in incomplete programming... a few bits were still high that were supposed to be low)
Maybe your particular programming hardware was flawed.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

krupski

Maybe your particular programming hardware was flawed.
There was no "hardware" (as in some kind of programming box).  To program an EEPROM byte, this is what was done:

Code: [Select]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; erase eeprom byte
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

ee.clr  pshb                            ;save b
        ldab    #eelat|byte|erase       ;eelatch, byte erase mode
        bsr     ee.main                 ;erase eeprom byte
        pulb                            ;restore b

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; program eeprom byte (data for byte is in ACCA)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

ee.wrt  pshb                            ;save b
        ldab    #eelat                  ;eelatch, byte write mode
        bsr     ee.main                 ;write eeprom byte
        pulb                            ;restore b

        rts                             ;return

ee.main stab    pprog                   ;write control bits
        staa    0,x                     ;write data to ee latch
        orab    #eepgm                  ;set vpp bit
        stab    pprog                   ;turn on vpp charge pump (program ee)

        ldy     #(eclk/7)*20            ;double Motorola's spec for reliability
        dey                             ;[4~] count down
        bne     *-2                     ;[3~] do rest

        clrb                            ;all bits off
        stab    pprog                   ;set ee to normal mode

        rts                             ;return



The programming "high voltage" was generated on-chip with a charge pump and programming a byte was all done in software (no "programmer" involved).
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

aarg

#19
Jan 19, 2018, 04:23 pm Last Edit: Jan 19, 2018, 04:26 pm by aarg
Did anyone else report this problem? I had the EVB board which runs code from ROM, not EEPROM so I didn't test it, but I'm still surprised. I just never heard anything about it. I played with HC11 for several years, but it was a while back.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

krupski

#20
Jan 19, 2018, 04:57 pm Last Edit: Jan 19, 2018, 04:59 pm by krupski
Did anyone else report this problem? I had the EVB board which runs code from ROM, not EEPROM so I didn't test it, but I'm still surprised. I just never heard anything about it. I played with HC11 for several years, but it was a while back.
Not reported as far as I know...

BTW, I used the Motorola EVBU board:


and when it was no longer manufactured, I used the Axiom EVBU board:


I did re-program the 16LV8 GAL to re-map the LCD port to a different address, but that would not impact the EEPROM in any way.

I was fortunate enough to have several samples of the rather rare ceramic package, windowed 68HC11E9 which could be UV erased (unlike the plastic OTP versions).  By the way, the eeprom "problem" was the same for both regular HC11 and ceramic HC11 chips.

I had probably a dozen sets of the HC11 "pink books" which I gave away to various people "in need". Now I don't have any left and I wish I did...... :(
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Coding Badly

Last bit might be true but that's as true for the linked EEPROM...
It is not an EEPROM.  You fail at basic reading comprehension.

Quote
High endurance : 10^12 times / byte
Let's see how that works out...

10^12/(365.24*24*60*60*1000) = 31.7 years

A failure can be expected in 31.7 years after writing every byte every millisecond.  A few orders of magnitude better than the AVR EEPROM (or any EEPROM).


septillion

@krupski, thanks! But I assume the EEPROM routines of the Arduino IDE are as spec'ed by AVR / sufficient.

It is not an EEPROM.  You fail at basic reading comprehension.
Doesn't matter. EEPROM, FRAM, battery backed up RAM, paper and quill. All what you wrote (last paragraph reply #14) still applies... You gain nothing except more write cycles which you can work  around by using multiple EEPROM bytes.
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

Go Up