Searching \ for '[PIC] Count 20M+ in EEPROM counter' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=count
Search entire site for: 'Count 20M+ in EEPROM counter'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Count 20M+ in EEPROM counter'
2006\01\16@174714 by Gerhard Fiedler

picon face
Just thought this might interest somebody... haven't seen anything along
these lines before. But then, it may be trivial... :)

I needed to count some 20M+ incidents, stored in nonvolatile storage
(EEPROM). Microchip's EEPROMs have 100k write cycles endurance spec'ed. A
simple 4-byte counter in EEPROM doesn't do it, as its low byte would get
written too often.

What I did is create a structure with an index and a moving 3-byte counter.
The 3-byte counter counts up to 0x18000 which is just a bit below 100k
(could count up to almost 100k without violating the spec). When it has
reached the max, the index gets bumped and the 3-byte counter gets
restarted from 0, but now one byte offset. Looks like this in EEPROM:

Index Data0 Data1 Data2 Data3 Data4 ...

The first counter is Data0..2 (with Index=0). When it is full, Index gets
incremented, and the next counter Data1..3 reset to 0. And so on, until the
max is reached (at which point I don't increment anymore, indicating an
overflow). On an increment, I write back only the byte(s) that got changed.
This way, no cell gets written more than 100k.

The total EEPROM storage required for up to Nmax counts is (Nmax/100k)+1
(if Nmax is smaller than 25.5M; above that it's one more).

Gerhard

2006\01\18@041910 by Shawn Wilton

picon face
Gerhard,
out of curiousity, what are you tracking that you have to maintain a record
of 20M events?  How long is your device expected run?

On 1/16/06, Gerhard Fiedler <spam_OUTlistsTakeThisOuTspamconnectionbrazil.com> wrote:
{Quote hidden}

> -

2006\01\18@053516 by Gerhard Fiedler

picon face
Shawn Wilton wrote:

> what are you tracking that you have to maintain a record of 20M events?

Number of gear changes in a vehicle (sports/off-road).

> How long is your device expected run?

I hope 10+ years :)  

I didn't want to lose out on the numbers of the real champ when it gets
there -- and I didn't want the EEPROM to be the weak link. Anyway, 100k is
too low, so there's a need for some way to increase that limit, even if it
shouldn't get to 20M.

And I'm almost sure there are other applications out there where someone
had to count more than 100k events in EEPROM. What did you guys do?

Gerhard

2006\01\18@055025 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> Shawn Wilton wrote:
>
> > what are you tracking that you have to maintain
> > a record of  20M events?
>
> Number of gear changes in a vehicle (sports/off-road).
>
> > How long is your device expected run?
>
> I hope 10+ years :)  

OK, let's say 10 years sharp...

That's 1 gear change aprox each 15 seconds, 24 hours a day,
365 days a year, during 10 years. Using the same gearbox ? :-)

> And I'm almost sure there are other applications out there
> where someone had to count more than 100k events in EEPROM.

Keeping a counter in RAM and copying to EEPROM regulary
(and probably saving to EEPROM on a power loss) ?

Using a Ramtron FRAM device ?

Jan-Erik.



2006\01\18@075656 by olin piclist

face picon face
Gerhard Fiedler wrote:
>> what are you tracking that you have to maintain a record of 20M events?
>
> Number of gear changes in a vehicle (sports/off-road).
>
>> How long is your device expected run?
>
> I hope 10+ years :)

That means you can count a gear change every 16 seconds for 10 years
continuously.  That sounds like rather a lot.  Don't they have to stop for
gas, oil changes, or to swap out those pine tree air fresheners once in a
while?


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\18@111022 by Gerhard Fiedler

picon face
Jan-Erik Soderholm wrote:

> OK, let's say 10 years sharp...
>
> That's 1 gear change aprox each 15 seconds, 24 hours a day,
> 365 days a year, during 10 years.

What's exactly your point? That 20M is enough? I haven't said otherwise.
Your numbers match mine: 20M /will/ be enough.


>> And I'm almost sure there are other applications out there where someone
>> had to count more than 100k events in EEPROM.
>
> Keeping a counter in RAM and copying to EEPROM regulary (and probably
> saving to EEPROM on a power loss) ?

How often is "regularly"? Saving to EEPROM on power loss can by tricky.
Probably needs extra components = extra cost.

> Using a Ramtron FRAM device ?

More expensive than the EEPROM in the processor. What are the advantages
this higher cost would buy me? (The higher speed of the FRAM is not needed,
and the additional space the EEPROM counter needs is there.)

Gerhard

2006\01\18@113326 by Larry G. Nelson Sr.

picon face
I did a speedometer system with odometer and to increase the life of the system I did 2 things. I do my updates periodically and not after each count. I also do update on power off detect with a cap keeping the micro alive long enough to do the write before going down. Another thing is I have 16 bit wide eeprom and use 3 sets of 16 bit locations for each byte. I can correct for soft errors with a vote system and rewrite. I also store the byte as true and compliment as an error check. So far over the several years these have been sold into the field there are no eeprom failures. These go into motorcycles as aftermarket components (primarily Harleys). They are in Mirror Gauges from a company called Maximum Products and there is some info with links on my web site ( http://www.mchipguru.com )

Larry


---- Gerhard Fiedler <.....listsKILLspamspam@spam@connectionbrazil.com> wrote:
{Quote hidden}

> --

2006\01\18@114137 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu]
>Sent: 18 January 2006 16:08
>To: EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu
>Subject: Re: [PIC] Count 20M+ in EEPROM counter
>
>
>Jan-Erik Soderholm wrote:
>
>> OK, let's say 10 years sharp...
>>
>> That's 1 gear change aprox each 15 seconds, 24 hours a day,
>365 days a
>> year, during 10 years.
>
>What's exactly your point? That 20M is enough? I haven't said
>otherwise. Your numbers match mine: 20M /will/ be enough.

I think his point is that 20 million writes is a grossly excessive target for the 10 year design life, unless vehicles really exist that are capable of running non-stop for 10 years, and also gearboxes/linkages that are capable of 20 million changes without failure or need of  rebuild (which would involve the vehicle having to stop) .  Why make life harder for yourself than you have to?

{Quote hidden}

A few extra components, a capacitor and maybe a diode to hold up the micro supply for the desired time, and some way of telling the micro that the supply is failing e.g. a supervisor IC or maybe just a comparator.  Some PIC's have a built in peripheral for this.

>
>> Using a Ramtron FRAM device ?
>
>More expensive than the EEPROM in the processor. What are the
>advantages this higher cost would buy me? (The higher speed of
>the FRAM is not needed, and the additional space the EEPROM
>counter needs is there.)

Possibly you could use a smaller device due to not having to spread the counter over such a large number of bytes, which would offset the cost somewhat.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\01\18@120453 by Michael Rigby-Jones

picon face


{Quote hidden}

It's a neat and effective scheme, but one thing you do need to watch when doing a lot of writes to only part of the EEPROM is that the whole eeprom needs to be periodicaly refreshed (i.e. every cell used needs to be read and written back) every x writes (1 million for the devices I've used, the datasheet specifies this number).

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\01\18@120959 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> Jan-Erik Soderholm wrote:
>
> > OK, let's say 10 years sharp...
> >
> > That's 1 gear change aprox each 15 seconds, 24 hours a day,
> > 365 days a year, during 10 years.
>
> What's exactly your point? That 20M is enough? I haven't
> said otherwise. Your numbers match mine: 20M /will/ be enough.

Fine.
Why not say "up to 100M" then... or 200M, or whatever.

My *point* was that it's a bit silly to design against
a specification that is quite unrealistic anyway.
*If* it is, that is... :-)

> Saving to EEPROM on power loss can by tricky.
> Probably needs extra components = extra cost.

OK, fine, I missed the "no extra cost" part...

>
> > Using a Ramtron FRAM device ?
>
> More expensive than the EEPROM in the processor. What are the
> advantages this higher cost would buy me?

Primarily unlimited number of writes. They specified 10**10
number of writes on older FRAM devices, but Ramtron says
"unlimited" on later parts...

Best Regards,
Jan-Erik.



2006\01\18@134421 by Herbert Graf

flavicon
face
On Wed, 2006-01-18 at 07:57 -0500, Olin Lathrop wrote:
> Gerhard Fiedler wrote:
> >> what are you tracking that you have to maintain a record of 20M events?
> >
> > Number of gear changes in a vehicle (sports/off-road).
> >
> >> How long is your device expected run?
> >
> > I hope 10+ years :)
>
> That means you can count a gear change every 16 seconds for 10 years
> continuously.  That sounds like rather a lot.  Don't they have to stop for
> gas, oil changes, or to swap out those pine tree air fresheners once in a
> while?

I don't know exactly what racing is involved, but "sports/off-road" can
be a shift a second depending on the stage. WRC is a good example, if
you watch the in car video of those stages, on the slower twisty stuff,
there is a gear shift a least every few seconds, sometimes more then one
in a second.

Now, to keep that pace, continuously for years, that's a little far
fetched, at least to me.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\18@162831 by Peter van Hoof
face picon face


--- Gerhard Fiedler <RemoveMElistsTakeThisOuTspamconnectionbrazil.com>
wrote:

{Quote hidden}

I think what I would use is use ram for counting and
use a cap and power down detection to power the chip
long enough to write the count to eeprom. when power
comes back on copy eeprom back to ram and resume
counting.

The number of power down/ power up cycles should be
low.

Peter van Hoof

2006\01\18@164648 by Shawn Wilton

picon face
Leave Gerhard alone guys.  So he wants a system that he *knows* will track
the number of shifts.  Big deal if it's last for 20 years when we're all
dead and the dogs have inherited the earth.  ;-)

Gerhard, how much EEPROM are you using?

On 1/18/06, Peter van Hoof <spamBeGonepvhoofspamBeGonespamyahoo.com> wrote:
{Quote hidden}

> -

2006\01\18@174959 by David VanHorn

picon face
>
>
> I needed to count some 20M+ incidents, stored in nonvolatile storage
> (EEPROM). Microchip's EEPROMs have 100k write cycles endurance spec'ed. A
> simple 4-byte counter in EEPROM doesn't do it, as its low byte would get
> written too often.


I've done this in other devices, by specifying several fields for the data,
and a pointer to which field is in use.  The pointer only gets updated when
you change fields, so it never wears out in any practical sense.

When writing the data, I do a readback. If the result is different, then
it's time to change storage locations, and update the pointer. Old data is
just left to rot.

2006\01\18@185751 by Jinx

face picon face
Gerhard, one thing occurs to me after reading some MChip
pdfs - AN562, AN601,and AN602

I can't find AN601 (DS00601A) or AN602 (DS00602A)
anywhere at MChip, perhaps they've been superceded. Or
perhaps the MChip wretched "search engine"....... > :-(

I've uploaded my CD copies

http://home.clear.net.nz/pages/joecolquitt/Mchip00601.pdf  (70kB)

http://home.clear.net.nz/pages/joecolquitt/Mchip00602.pdf  (60kB)

"Write Modes In EEPROMs" in AN601 is interesting

"A general rule to follow in choosing write modes is that
the larger the number of bytes being written in a single
instruction, the longer the device will last. For example,
in byte mode a device might start to fail after 300,000
cycles under a particular set of conditions, but the
device may last 600,000 cycles in page mode under
the same conditions. In block mode the device might
last 1 million cycles, under the same conditions"

and charge pump voltage is also discussed

"Generally, the lower the charge pump voltage the
better the endurance (there is a limit since the charge
pump voltage needs to be high enough to program the
cell) ........."

I wonder then, if you drop Vdd (easy enough to do with
a resistance-controlled regulator) before writing to EEPROM,
you'd up the endurance ???

2006\01\18@201426 by andrew kelley

picon face
part 1 566 bytes content-type:text/plain; charset=ISO-8859-1 (decoded quoted-printable)

> I think what I would use is use ram for counting and
> use a cap and power down detection to power the chip
> long enough to write the count to eeprom. when power
> comes back on copy eeprom back to ram and resume
> counting.
>
> The number of power down/ power up cycles should be
> low.
>
> Peter van Hoof

Agreed.  I did something similar where a device required fail-safe
power.. looked like the attached jpg as far as p/s went..

andrew
(sorry its big.. I dont have PSP on here..)


part 2 6111 bytes content-type:image/jpeg; name="schm.jpg" (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2006\01\18@212417 by Jinx

face picon face
power.. looked like the attached jpg as far as p/s went..

andrew
(sorry its big.. I dont have PSP on here..)

Irfan does gif

http://www.irfanview.com/


2006\01\19@044748 by Alan B. Pearce

face picon face
>Leave Gerhard alone guys.  So he wants a system that
>he *knows* will track the number of shifts.  Big deal
>if it's last for 20 years when we're all dead and
>the dogs have inherited the earth.  ;-)

Yeah, I couldn't get over the bashing either.

He came up with a way of counting huge counts without exceeding the write
cycles of the EEPROM he's using.

He shared it - and everyone hits him for the huge potential count it can do.

The fact that it does considerably more than he is likely to need is surely
neither here nor there. The technique may be useful to someone else.

2006\01\19@072903 by Gerhard Fiedler

picon face
Alan B. Pearce wrote:

> Yeah, I couldn't get over the bashing either.
>
> He came up with a way of counting huge counts without exceeding the
> write cycles of the EEPROM he's using.
>
> He shared it - and everyone hits him for the huge potential count it can
> do.
>
> The fact that it does considerably more than he is likely to need is
> surely neither here nor there. The technique may be useful to someone
> else.

Thank you, Alan! That was nice, for a change :)  

Ok, here's a summary, from my angle... (The items are in no specific order.
The numbers are just to separate items.)


1- I may not need 20M+ counts (I never said I did, it's not a
"specification", and I certainly did not "design against it"), but it
happens that the method supports it, so I stated so. I needed /some/ method
to count more than the guaranteed write count (100k). In my case the
possibly excessive count was for free (just setting a constant in the code
so that the counters filled the available EEPROM), so why limit myself to
less and miss the thrill to see a unit in 20 years with a 15M shift count
and still going, working with the third transmission? It wasn't making
anybody's life any "harder".

2- There may be other applications (where 20M+ really are needed) that
could use a similar technique. That was the real purpose of my post, and it
seems most of the posters have missed it (Alan didn't :). Hopefully not
most of the others :)

3- All the supposedly "better" methods suggested the use of "a few extra
components" (e.g. 0.5 F caps, FRAM devices) and a change to the PCB. Nobody
even tried to explain what the benefit (for the application) of the added
cost is. The (for other reasons, and prior to this counter implementation)
selected micro has an EEPROM, and it's big enough for my 20M counter... In
fact, that's the reason for the 20M+: I just set the index limit so that it
fills the available EEPROM.

A funny side line is that the only stated added benefit of such an added
device (FRAM) was that it supports 10G writes -- being that the device was
suggested because designing for 20M counts was considered excessive. Now
talk about consistency in argumentation... When I have an application where
I need to design a persistent counter for 10G counts, I make sure to
consider FRAM (or another method), but until then I stay with the 20M+ that
I know I won't really need, thank you :)

4- One thing I forgot telling is that I set a flag whenever the index gets
incremented that causes an EEPROM refresh on the next power-up. This is
(again) a bit on the safe side... I hope nobody takes offense in this
safety margin :)

5- David contributed another suggestion: write until the read-back is
wrong. While this probably gets a higher number of writes out of a cell,
I'm not sure this is safe... couldn't it be that the cell reads back ok
right after the write, but not, say, after the next power cycle?

What David didn't say is how he manages to multiply the count. The "trick"
of my suggestion is to use a 3 or 4 byte counter that moves over by one
byte at every 100k counts. Maybe obvious, maybe not, but it seems to me
that this is the most efficient way to have a persistent counter for large
counts in EEPROM -- for whatever reason you might need it.

Thanks for your thoughts,
Gerhard

2006\01\19@073526 by Gerhard Fiedler

picon face
Jinx wrote:

> http://home.clear.net.nz/pages/joecolquitt/Mchip00601.pdf  (70kB)
> http://home.clear.net.nz/pages/joecolquitt/Mchip00602.pdf  (60kB)
>
> "Write Modes In EEPROMs" in AN601 is interesting
>
> "A general rule to follow in choosing write modes is that the larger the
> number of bytes being written in a single instruction, the longer the
> device will last. For example, in byte mode a device might start to fail
> after 300,000 cycles under a particular set of conditions, but the
> device may last 600,000 cycles in page mode under the same conditions.
> In block mode the device might last 1 million cycles, under the same
> conditions"

I'm using the internal EEPROM of a PIC (that's why I used the PIC tag :),
and I'm not aware of page or block modes for these devices.

Anyway, with an external EEPROM, would this mean that if you write only
complete blocks, you get a higher endurance? OTOH, there are more cells
you're writing to; does this increase the probability of failure? I'm not
quite clear about the mechanisms here.

> "Generally, the lower the charge pump voltage the better the endurance
> (there is a limit since the charge pump voltage needs to be high enough
> to program the cell) ........."
>
> I wonder then, if you drop Vdd (easy enough to do with a
> resistance-controlled regulator) before writing to EEPROM, you'd up the
> endurance ???

It sure sounds like this. Sounds like it was a good idea to run EEPROMs on
as low a Vdd as you can.

Gerhard

2006\01\19@073945 by Shawn Wilton

picon face
G, you still don't mention the size of your EEPROM.  I want to calculate the
efficiency of your algorithm versus mine for the fun of it.

I figure with a 1024B EEPROM, I could get 51.2M events.  But I have no idea
which EEPROM it is you're writing to.  I suppose I could try working it back
from what you're said, but hey, it's easier to just ask.  :-)


On 1/19/06, Gerhard Fiedler <RemoveMElistsspamTakeThisOuTconnectionbrazil.com> wrote:
{Quote hidden}

> -

2006\01\19@074546 by Shawn Wilton

picon face
Which uC are you using?  The (for example) pic18f452 specifies a read/write
cycle of 1E6.  Not bad!  So upgrade your chip and maybe you can run your
device until dogs really do run over the world...

Doing some hunting around in various data sheets, I do believe I have
answered my own question regarding EEPROM size (256B?).

On 1/19/06, Gerhard Fiedler <listsEraseMEspam.....connectionbrazil.com> wrote:
{Quote hidden}

> -

2006\01\19@074810 by Jinx

face picon face
> I'm using the internal EEPROM of a PIC (that's why I used the PIC
> tag :), and I'm not aware of page or block modes for these devices

I mentioned it if anyone (or even yourself one day) was using an
external. It's also another aspect to how EEPROM works and
can be less stressed

2006\01\19@085349 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: EraseMEpiclist-bouncesspammit.edu [RemoveMEpiclist-bouncesEraseMEspamEraseMEmit.edu]
>Sent: 19 January 2006 12:29
>To: RemoveMEpiclistspam_OUTspamKILLspammit.edu
>Subject: Re: [PIC] Count 20M+ in EEPROM counter
>
>
>Ok, here's a summary, from my angle... (The items are in no
>specific order. The numbers are just to separate items.)
>
>
>1- I may not need 20M+ counts (I never said I did, it's not a
>"specification", and I certainly did not "design against it")

Sorry, but in your first post you said "I needed to count some 20M+ incidents".  From most peoples point of view, that sounds very much like a design specification.  You may feel it's being pedantic to argue about this, but if you really only needed to measure, say 500k events, perhaps some valid alternatives could have been suggested.

>3- All the supposedly "better" methods suggested the use of "a
>few extra components" (e.g. 0.5 F caps, FRAM devices) and a
>change to the PCB. Nobody even tried to explain what the
>benefit (for the application) of the added cost is. The (for
>other reasons, and prior to this counter implementation)
>selected micro has an EEPROM, and it's big enough for my 20M
>counter... In fact, that's the reason for the 20M+: I just set
>the index limit so that it fills the available EEPROM.

The advtange of an FRAM (and I'm absolutely sure this was stated) is that is has no wait time on writes, and has infinite (to all intents and purposes) endurance.  If neither of those are important, then obviously the higher cost is not justifiable.

I searched through the posts in this topic and couldn't find any mention of 0.5 F caps apart from your post.  The size of cap required to complete an EEPROM write would be much smaller than this, bearing in mind the PIC would only need to keep running for ~20ms absolute worst case (three cells for the counter and the index cell).  Quick calculation shows a capacitance in the 10's of uF range would probably suffice, especialy if you have a low power nano-watt PIC.  It's a very relevant discussion anyway, as writes to EEPROM are vulnerable to corruption during brown out events.  If this occured whilst you were writting your index byte, it could mean you start re-using one of the previous cells that has already suffered ~100k writes.


>4- One thing I forgot telling is that I set a flag whenever
>the index gets incremented that causes an EEPROM refresh on
>the next power-up. This is
>(again) a bit on the safe side... I hope nobody takes offense
>in this safety margin :)

In that case the safety margin depends on a condition which you presumably have no real control over, the time between power up events, and the number of gearchanges.  Clearly this will almost certainly be ok, in the same way that almost certainly you won't be recording 20M events in 10 years ;)

>The "trick" of my suggestion is to use a 3 or 4 byte counter
>that moves over by one byte at every 100k counts. Maybe
>obvious, maybe not, but it seems to me that this is the most
>efficient way to have a persistent counter for large counts in
>EEPROM -- for whatever reason you might need it.

FWIW I do think it's a neat trick, it maximises the endurance of every cell used in the counter without any being wasted.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\01\19@105420 by David VanHorn

picon face
>
> 5- David contributed another suggestion: write until the read-back is
> wrong. While this probably gets a higher number of writes out of a cell,
> I'm not sure this is safe... couldn't it be that the cell reads back ok
> right after the write, but not, say, after the next power cycle?


I suppose it could.. Depends on the cell structure probably, but I doubt it.

We didn't pick up any problems in accelerated life testing.
None of the systems will likely out-run the counter life in real life.

What David didn't say is how he manages to multiply the count.


I'm not sure what you mean here. My counters were incremented per event.
The idea is that while the guaranteed number of writes is relatively small,
the typical life is significantly larger. So I wanted to get as many counts
into the space as possible.


> The "trick"
> of my suggestion is to use a 3 or 4 byte counter that moves over by one
> byte at every 100k counts. Maybe obvious, maybe not, but it seems to me
> that this is the most efficient way to have a persistent counter for large
> counts in EEPROM -- for whatever reason you might need it.


Works for me. It just dosen't take advantage of the difference between
guaranteed and typical lifetime.

2006\01\19@174752 by Shawn Wilton

picon face
On 1/19/06, Michael Rigby-Jones <RemoveMEMichael.Rigby-JonesTakeThisOuTspamspambookham.com> wrote:
>
> Sorry, but in your first post you said "I needed to count some 20M+
> incidents".  From most peoples point of view, that sounds very much like a
> design specification.  You may feel it's being pedantic to argue about this,
> but if you really only needed to measure, say 500k events, perhaps some
> valid alternatives could have been suggested.



It's in the sch. posted by Andrew Kelley.

2006\01\19@180612 by Jinx

face picon face
> I'm using the internal EEPROM of a PIC (that's why I used the
> PIC tag :)

Ah, I wondered why I had the impression you weren't and looked
at the original post. You'd said "Microchip's EEPROMs have 100k
write cycles endurance spec'ed" and I think I drew the conclusion
this was an external. But that's OK, no big whoop, just a misunder-
standing

> and I'm not aware of page or block modes for these devices

AFAIK all PICs except the 30F have single-byte EEPROM access

The only block operation I know of in not-30F is the block write
to Flash

> Anyway, with an external EEPROM, would this mean that if you
> write only complete blocks, you get a higher endurance? OTOH,
> there are more cells you're writing to; does this increase the
> probability of failure? I'm not quite clear about the mechanisms here

It's explained in AN601 -

"The charge pump voltage is used to program however
many EEPROM-cells are being programmed. For
example, in byte mode, all the cells in a byte (8 to 16)
are biased with the charge pump voltage. In block
mode, all the cells in the array (up to 100,000,
depending on the device) are biased with the charge
pump voltage. The charge pump is like a current
source during conditions of high load, so the voltage
put out by the charge pump will be reduced slightly if
more bytes are being written. If the whole array is being
programmed then the charge pump voltage will be
significantly reduced, but the programming current Ipp
will be very high

Generally, the lower the charge pump voltage the
better the endurance......."

> It sure sounds like this. Sounds like it was a good idea to run
> EEPROMs on as low a Vdd as you can

On re-reading the AN, and if I were in your situation, I think
I might try lowering Vdd just for EEPROM writes (unless
you didn't need 5V Vdd at any time, in which case run the
PIC with a permanent low Vdd anyway)

There's also the PIC's Flash memory don't forget. It's not
as high endurance, but there could be a lot of it sitting idle

I might prefer doing all the logging in RAM and writing
periodically to EEPROM, rather than using EEPROM for
every single event. And having the power-fail system for
not losing RAM data

2006\01\20@072606 by Joe McCauley

picon face
Well whereas I agree that 20 million might be excessive for this particular
application, the idea & algorithm may have merit. I have an application
which needs to count up to 10 million (ideally, as the system it replaces
does this), not loose counts (really important), and operate over a similar
lifetime. For cost reasons & pin count, external parts are out. I did try
saving the 8 3 byte counters to EEPROM on power down. It worked well most of
the time. Doing things Gerhard's way may help me. I'll certainly have a look
at it as it would appear to operate more efficiently EEPROM wise than what I
was going to try.

The 16F876A I'm testing has >1.5 million counts in EEPROM & all is well. I'd
love to be able to guarantee 10 million. But....

I've read here
<http://oase.uci.kun.nl/~mientki/pic/libs_hw/eeprom_problems.html> that
writing to one place reduces the endurance of the entire EEPROM. Anyone else
have any comments on this?

Joe


{Quote hidden}

2006\01\20@072805 by Gerhard Fiedler

picon face
Shawn Wilton wrote:

> Which uC are you using?  

This device is using one of the 18F6722 family. But this is not really
relevant because the built-in EEPROMs seem to be pretty much the same WRT
endurance.

> The (for example) pic18f452 specifies a read/write cycle of 1E6.  Not
> bad!  

I suppose you're looking at D124, and forgetting about D120? Or you're
looking at the typical value and not counting the minimum value? FWIW, I
was looking at the minimum value for D120, and this is 100k for my chip and
the 18F452.

> So upgrade your chip and maybe you can run your device until dogs really
> do run over the world...

Doesn't look like this would be an upgrade :)

> Doing some hunting around in various data sheets, I do believe I have
> answered my own question regarding EEPROM size (256B?).

In the chip in the device I'm using it's 1k.

Gerhard

2006\01\20@073921 by Gerhard Fiedler

picon face
Jinx wrote:

>> Anyway, with an external EEPROM, would this mean that if you write only
>> complete blocks, you get a higher endurance? OTOH, there are more cells
>> you're writing to; does this increase the probability of failure? I'm
>> not quite clear about the mechanisms here
>
> It's explained in AN601 - [...]

It explains how the endurance goes up with lower charge pump voltage, and
how writing more cells at a time helps reduce this voltage. I still don't
understand (and didn't see anything mentioned) how writing more cells
affects the failure probability: if the failure probability goes up with
every write to a cell, writing more cells could also increase the failure
probability (for the cells you don't really change, the ones you just write
as part of the block write).


>> It sure sounds like this. Sounds like it was a good idea to run EEPROMs
>> on as low a Vdd as you can
>
> On re-reading the AN, and if I were in your situation, I think I might
> try lowering Vdd just for EEPROM writes (unless you didn't need 5V Vdd
> at any time, in which case run the PIC with a permanent low Vdd anyway)

Both good ideas, but there are a number of 5 V devices on the board and I'm
not in a position anyway to make that amount of changes to the board.
Especially given that the current solution works (at least nobody tried to
claim otherwise :)

> There's also the PIC's Flash memory don't forget. It's not as high
> endurance, but there could be a lot of it sitting idle

Yes, that's true. But I think you have to write in blocks to the program
flash, right? (At least you have to erase it in blocks, and most often a
write requires an erase.) Which then makes this a more complex solution.

> I might prefer doing all the logging in RAM and writing periodically to
> EEPROM, rather than using EEPROM for every single event. And having the
> power-fail system for not losing RAM data

Yes, all true, but this also requires a board revision. Is/was not really
in my budget.

Gerhard

2006\01\20@074657 by Gerhard Fiedler

picon face
Shawn Wilton wrote:

> G, you still don't mention the size of your EEPROM.  

1024 bytes

> I want to calculate the efficiency of your algorithm versus mine for the
> fun of it.

What's your algorithm?

> I figure with a 1024B EEPROM, I could get 51.2M events.  

If I use the entire 1024 bytes for one counter, I get:
- 2 bytes for the index
- 1022 revolving 3-byte counters that count to 100k

That gives 1022*100k events = 102.2M events

Gerhard

2006\01\20@075054 by Gerhard Fiedler

picon face
David VanHorn wrote:

> We didn't pick up any problems in accelerated life testing. None of the
> systems will likely out-run the counter life in real life.

Thanks for sharing that experience. I will make sure to add that to my
"tool chest" :)

>> What David didn't say is how he manages to multiply the count.
>
> I'm not sure what you mean here. My counters were incremented per event.
> The idea is that while the guaranteed number of writes is relatively
> small, the typical life is significantly larger. So I wanted to get as
> many counts into the space as possible.

That was also my goal. What I thought was the special trick is to use a
3-byte counter, write only changed cells back, and move the counter over
only by 1 byte once the lifetime is over (because it's only the lowest byte
that gets written on every count, the higher bytes get written considerably
less often and can be re-used for the next counter position).

Gerhard

2006\01\20@082449 by Jinx

face picon face
> I still don't understand (and didn't see anything mentioned) how
> writing more cells affects the failure probability: if the failure
> probability goes up with every write to a cell, writing more cells
> could also increase the failure probability (for the cells you don't
> really change, the ones you just write as part of the block write).

I see what you mean. But although you're writing to more cells,
it's at a lower voltage. Maybe the two cancel out ? Don't know,
might have to read around some more

The Predictive Software would be useful

Home Page/Development Tools/Software/Total Endurance

Examples are given in AN562 (70kB)

http://ww1.microchip.com/downloads/en/AppNotes/00562.pdf

"Microchip has done extensive predictive laboratory studies on
Microchip 2- and 3-wire Serial EEPROMs. These studies led
to the concept of using the computer to predict the theoretical
wear out of the floating gate and ultimately to project the point
in time of a product's life cycle when the first non-volatile
memory bit or periphery failure should occur"

Total Endurance Quick Start Guide (235kB)

http://ww1.microchip.com/downloads/en/DeviceDoc/TotEnd_QS_51342A.pdf

s/w (12MB)

ww1.microchip.com/downloads/en/DeviceDoc/Total%20Endurance%20v401%20I
nstall.exe

Presumably for internal EEPROM, you'd use 1 byte per cycle

2006\01\20@083542 by Gerhard Fiedler

picon face
Michael Rigby-Jones wrote:

>>1- I may not need 20M+ counts (I never said I did, it's not a
>>"specification", and I certainly did not "design against it")
>
> Sorry, but in your first post you said "I needed to count some 20M+
> incidents".  From most peoples point of view, that sounds very much like
> a design specification.  You may feel it's being pedantic to argue about
> this, but if you really only needed to measure, say 500k events, perhaps
> some valid alternatives could have been suggested.

Ok, you're right; I said I "needed" 20M+, and I may not need it. Still --
nobody came up with a constructive suggestion what value would be more
appropriate; the only thing everybody said was that 20M was too much. I
knew it was too much, that's why I chose the value. I wouldn't be happy
with any value that would not exceed the expected life time by a good
margin. There's this Gauss distribution, and it's quite possible that some
devices will outlive the average lifetime by quite a bit. (I don't know yet
neither the average nor the standard deviation, so I'm operating on
speculation and typical values.)

So for all the ones who say that 20M is way too high, what would be the
value that you can reasonably guarantee won't be exceeded? Unless you can
suggest a better suited maximum count, it doesn't really make sense to
start arguing that 20M is too high, does it? What would be the advantages
(for the application) to go with a lower maximum count? What could I have
saved if I went with 500k (which seems too low to me)?


> I searched through the posts in this topic and couldn't find any mention
> of 0.5 F caps apart from your post.  

Shawn already answered that, but he cited the wrong passage of your message
:)  It's in a schematics contributed by Andrew.


> It's a very relevant discussion anyway, as writes to EEPROM are
> vulnerable to corruption during brown out events.  If this occured
> whilst you were writting your index byte, it could mean you start
> re-using one of the previous cells that has already suffered ~100k
> writes.

It is relevant; thanks for pointing this out. I'll have to think that over
a bit...

Gerhard

2006\01\20@115309 by Shawn Wilton

picon face
On 1/20/06, Gerhard Fiedler <listsSTOPspamspamspam_OUTconnectionbrazil.com> wrote:
>
> Shawn Wilton wrote:
>
> > Which uC are you using?
>
> This device is using one of the 18F6722 family. But this is not really
> relevant because the built-in EEPROMs seem to be pretty much the same WRT
> endurance.



Yeah, I was asking because the 18F452 for example, has only 256B of memory.

> The (for example) pic18f452 specifies a read/write cycle of 1E6.  Not
> > bad!
>
> I suppose you're looking at D124, and forgetting about D120? Or you're
> looking at the typical value and not counting the minimum value? FWIW, I
> was looking at the minimum value for D120, and this is 100k for my chip
> and
> the 18F452.


True.  Looked it over  and yes,  1E5 cycles typical.  Was only glancing at
the front page.  Seems a bit misleading..

{Quote hidden}

In that case, using circular buffers, you could in theory achieve around 50M
events


Gerhard
>
> -

2006\01\20@120447 by Shawn Wilton

picon face
>
> > I searched through the posts in this topic and couldn't find any mention
> > of 0.5 F caps apart from your post.
>
> Shawn already answered that, but he cited the wrong passage of your
> message
> :)  It's in a schematics contributed by Andrew.


Went back to look at how gmail sent that message, and that's really
strange.  That's now how I responded.  I've been having a heck of a time
with the new Firefox and gmail not working together.  Half the time I can't
send messages, the other half the time I can't login/logout.  Driving me
absolutely nuts.

--


Shawn Wilton (b9 Systems)
http://black9.com

2006\01\20@222628 by Gerhard Fiedler

picon face
Joe McCauley wrote:

> I've read here
> <http://oase.uci.kun.nl/~mientki/pic/libs_hw/eeprom_problems.html> that
> writing to one place reduces the endurance of the entire EEPROM. Anyone else
> have any comments on this?

Haven't read that link specifically, but this is specified (the difference
between D120 and D124). You have e.g. a minimum cell endurance of 100k for
each cell (D120), but you should refresh the whole EEPROM after e.g. 1M
writes (D124) to /any/ of the cells (that is, counting all writes to all
cells).

Gerhard

2006\01\20@223050 by Gerhard Fiedler

picon face
Shawn Wilton wrote:

> True.  Looked it over  and yes,  1E5 cycles typical.  Was only glancing at
> the front page.  Seems a bit misleading..

Front page is marketing material :)

>> In the chip in the device I'm using it's 1k.
>
> In that case, using circular buffers, you could in theory achieve around
> 50M events

Not sure how you get 50M, but I'm getting 100M (see an earlier message).

Gerhard

2006\01\20@223927 by Shawn Wilton

picon face
On 1/20/06, Gerhard Fiedler <spamBeGonelistsSTOPspamspamEraseMEconnectionbrazil.com> wrote:
>
> Shawn Wilton wrote:
>
> > In that case, using circular buffers, you could in theory achieve around
> > 50M events
>
> Not sure how you get 50M, but I'm getting 100M (see an earlier message).


Using a circular buffer, not your method.  I like your method for ultimate
capacity, but a circular buffer is much easier to implement.  :-)

Gerhard
>
> -

2006\01\21@065636 by Gerhard Fiedler

picon face
Shawn Wilton wrote:

>>> In that case, using circular buffers, you could in theory achieve around
>>> 50M events
>>
>> Not sure how you get 50M, but I'm getting 100M (see an earlier message).
>
> Using a circular buffer, not your method.  I like your method for ultimate
> capacity, but a circular buffer is much easier to implement.  :-)

Still not sure how you get 50M. If I understand your idea of a circular
buffer correctly, you use a buffer of 511 2-byte counters (counting to
2^16) with a 2-byte index field. This counts 33M4 events (511 * 2^16). Or
you use a buffer of 340 3-byte counters (counting to 100k) with a 2-byte
index field. This counts 34M events (340 * 100k).

So what am I missing here? How's your buffer structured?

Gerhard

2006\01\21@125711 by David VanHorn

picon face
> > Using a circular buffer, not your method.  I like your method for
> ultimate
> > capacity, but a circular buffer is much easier to implement.  :-)


A significant weakness though, when the first bit dies in the array, it's
over.

2006\01\21@163232 by Shawn Wilton

picon face
There is no array to speak of.

To answer both you and Gerhard:
http://atmel.com/dyn/resources/prod_documents/doc2526.pdf


On 1/21/06, David VanHorn <KILLspamdvanhornspamBeGonespammicrobrix.com> wrote:
>
> > > Using a circular buffer, not your method.  I like your method for
> > ultimate
> > > capacity, but a circular buffer is much easier to implement.  :-)
>
>
> A significant weakness though, when the first bit dies in the array, it's
> over.
> -

2006\01\21@173727 by Mike Singer

picon face
Gerhard Fiedler wrote:
> ...What I thought was the special trick is to use a
> 3-byte counter, write only changed cells back, and move the counter over
> only by 1 byte once the lifetime is over (because it's only the lowest byte
> that gets written on every count, the higher bytes get written considerably
> less often and can be re-used for the next counter position).

There is exact number for "considerably less often", it's 256 for the
next byte. Not that much if we are talking about getting tens of
millions out of 100K device.

Regards,
Mike

2006\01\21@180422 by Mike Singer

picon face
David VanHorn wrote:
> I've done this in other devices, by specifying several fields for the data,
> and a pointer to which field is in use.  The pointer only gets updated when
> you change fields, so it never wears out in any practical sense.

There is exact number the pointer getting updated for 8-bit devices. It's 256.
256 * 100K =~ 25M, pretty much close to specified value (20M).
Paying attention to numbers makes Engineer according to Olin ;-)


> When writing the data, I do a readback. If the result is different, then
> it's time to change storage locations, and update the pointer. Old data is
> just left to rot.

Wearing out hardware is not a good idea in my opinion.
Change low byte(s) address(es) every 256 counts circularly, don't wait
the result gets different
Who can guarantee that your test reveals worn cell before the cell
reveals you.  Wear out cells equally.

Regards,
Mike.

2006\01\22@123539 by Gerhard Fiedler

picon face
Mike Singer wrote:

>> ...What I thought was the special trick is to use a
>> 3-byte counter, write only changed cells back, and move the counter over
>> only by 1 byte once the lifetime is over (because it's only the lowest byte
>> that gets written on every count, the higher bytes get written considerably
>> less often and can be re-used for the next counter position).
>
> There is exact number for "considerably less often", ...

Yes, there is -- I just thought this was enough to get started :)

> ... it's 256 for the next byte.

This would be if you use a 2-byte counter and only write 65k events to the
counter. If you use a 3-byte counter and write 100k events, the number is
higher than 256: you write 1 time to it while it's the 3rd byte of counter
N and 390 times while it's the 2nd byte of counter N+1.

> Not that much if we are talking about getting tens of millions out of
> 100K device.

Not sure where the tens of millions come in, but the whole deal was to not
pass 100k writes for one byte. Which, after what I've read about EEPROM
endurance, is not good enough if you really want to go safe.

Gerhard

2006\01\22@124049 by Gerhard Fiedler

picon face
Mike Singer wrote:

> David VanHorn wrote:
>> I've done this in other devices, by specifying several fields for the data,
>> and a pointer to which field is in use.  The pointer only gets updated when
>> you change fields, so it never wears out in any practical sense.
>
> There is exact number the pointer getting updated for 8-bit devices. It's 256.
> 256 * 100K =~ 25M, pretty much close to specified value (20M).
> Paying attention to numbers makes Engineer according to Olin ;-)

Are you suggesting to use one EEPROM byte to count until 256, then
increment a pointer and use the next EEPROM byte to count the next 256
events? How would you reach 20M (or 25M) counts with this scheme?

> Wear out cells equally.

Why this?

Gerhard

2006\01\22@130015 by Gerhard Fiedler

picon face
Shawn Wilton wrote:

> There is no array to speak of.
>
> To answer both you and Gerhard:
> http://atmel.com/dyn/resources/prod_documents/doc2526.pdf

Sorry, but that doesn't answer my question; it's too generic and allows all
kinds of strategies. How exactly do you get your 50M counts out of 1024
bytes of EEPROM storage when writing to each cell max. 100k times? How do
you structure the buffer? How do you increment the count? How do you
calculate the current count?

Gerhard

2006\01\22@135814 by Rolf

face picon face
So, this thread has been alive for long enough to capture my interest
even though I do not need the solution myself. Here's how I would get
67M counts ot of 1024 bytes of EEPROM without exceeding 100K writes per
cell (in fact, keeping about 30% lower than the limit).

Keep two EEPROM bytes for a pointer to EEPROM, these will be the last
two bytes in EEPROM. Initially pointer is set at 0x0000

Use a 2 byte counter at the pointer position. Increment that counter at
each event.
At the 2 byte overflow, increment the pointer. This will be at 256^2
counts (65536).
What was the low byte of the 2-byte counter now becomes the high byte of
the next pointer.
EEPROM now looks like:
0x00 0x00, 0x00, ..., ... ......., ..., 0x00, 0x01

Byte 1 (the second byte) has been written 65K times.

With the current pointer, Byte 1 will be written another 256 times as
the High byte of the next pointed value, giving a total of
65792 writes.

To calculate the count it is a simple case of 65536 * Pointer + 2byte
value at pointer

My math indicates with 1024 bytes EEPROM the numbers are:

Max value: 1021 * 65536 + 65535 = 66,977,791

byte 0 of EEPROM gets 256 writes.
byte 1-1020 get 65792 writes.
byte 1021 gets 65536 writes.
byte 1022 gets 3 writes
byte 1023 gets 768 writes

With some more thought, and a more complicated count mechanism, I am
sure I could get close to 100M count in 1024 bytes, but would be much
more complex (I think).

with 256 bytes EEPROM I could get: 16.5M count

Rolf

Gerhard Fiedler wrote:
{Quote hidden}

2006\01\22@143931 by Robert Rolf

picon face
You could squeeze a little more count range out of this approach by
recognizing the special case of 0x400 for the pointer and reusing
the byte at 0 for 65536 additional counts (pointer wrap around).
You'd only need to test byte 1022 for bit 2=1 on overflows of the low
byte of the current counter and increment byte 0 instead of 1022.

If you bent the spec a bit, since it is a MINIMUM guarantee at MAX
temperature, use 131584 as your use limit per byte (32% more than spec)
and just go around your 1024 bytes a second time when 1022 is 4 or greater.

And you would read back the counter to confirm that it incremented correctly,
and if it didn't, increment the pointer AND a 'spare' 'errorcount' byte
that would account for this in the 'totals' calculation by subtracting
655356 for the bad cell. The new counter for a bad cell would
simply be a copy of the last good count value.

Robert

Rolf wrote:
{Quote hidden}

2006\01\22@172434 by Gerhard Fiedler

picon face
Rolf wrote:

> So, this thread has been alive for long enough to capture my interest
> even though I do not need the solution myself. Here's how I would get
> 67M counts ot of 1024 bytes of EEPROM without exceeding 100K writes per
> cell (in fact, keeping about 30% lower than the limit).

If it had captured your interest a bit earlier (Jan 20), you probably would
have read the message where I show how I get 102M (1022 * 100k) writes :)
Quite similar to your description.

> With some more thought, and a more complicated count mechanism, I am
> sure I could get close to 100M count in 1024 bytes, but would be much
> more complex (I think).

The thought involved is not so much more, and the mechanism is only a bit
more complex. Instead of 2-byte counters you'd use 3-byte counters and
count each one to 100k (or a bit less, if you want to discount the 2nd and
3rd byte writes).

My question was what the exact way is that Shawn calculates his 50M, and
whether there's some advantage to his algorithm that I don't yet see
(because I don't know it :). These 50M is a number that doesn't make much
sense to me in this context. You just showed that with a 2-byte counter
(the probably simplest algorithm) you get some 67M, with a 3-byte counter
you get 100M+.

Gerhard

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...