Flash write issue

Hi all guys,

I am requested to add some time-clock information in flash, to indicate
how long the device is used by end-user.
user can read but have no power to change it.

I have some puzzles about flash write issue.

1. Can I write a part of flash unit(i.e. 16 bytes) instead of one
sector?

2. Can I do write operation for not 0xff content(not erase before
write)?

3. Write/erase flash will hold whole CPU resource?
I means when the write/erase is processing, Can CPU run some other
interupt things or other tasks?


P.S.
I am not familar with chip related programing, Any suggestion is
appreciated and welcome!

Regards,
Sailor

On 18 Aug 2005 05:27:56 -0700, "sailor.gu@gmail.com"
<sailor.gu@gmail.com> wrote:

[...]
>I have some puzzles about flash write issue.

As always, the answers are "it depends," but I'll try to give you as
much info below as I can.
>
>1. Can I write a part of flash unit(i.e. 16 bytes) instead of one
>sector?

Yes, but you must _erase_ an entire page (sector?) at a time.

>
>2. Can I do write operation for not 0xff content(not erase before
>write)?

Generally, you can change any 1 bit to 0 without erasing.  To change
0s back to 1s, an erase is required.

>
>3. Write/erase flash will hold whole CPU resource?
>I means when the write/erase is processing, Can CPU run some other
>interupt things or other tasks?

The micro can (and usually will) continue to run during the flash
programming cycle.  The issue is whether Flash memory is accessible
during the programming cycle, and whether you program needs access to
any inaccessible memory.

For example, if your interrupt vectors become inaccessible during
Flash programming, no interrupts can be serviced, or you'll get an
incorrect vector and your program is off to see the wizard.

Something else to watch out for: Flash tends to have cycle limits.  A
typical limit for program flash is 10,000 erase/write cycles.  If you
re-write such flash once a second for your time clock, you'll wear out
the flash in a little under 3 hours.  If your Flash is good for
100,000 cycles, you'll still only get 30 hours.  Look up "wear
leveling" to find some strategies for extending this.

HTH,

                               -=Dave
-- 
Change is inevitable, progress is not.

Hi Dave,

Very thanks for your kind help.
Your clarification s very clear and useful for me.

but there are still some problems:

1. As you said, change 1s to 0s need not erase, so it is not a
write/erase cycle, right?

2. write a bit is much rapider than erase/write sector, right?
   so even  I do bit-write operation per one minute, its impact can be
ignored, right?

Regards,
Salor

"sailor.gu@gmail.com" wrote:

> 1. As you said, change 1s to 0s need not erase, so it is not a
> write/erase cycle, right?

Correct, it is only a write.  No erasure is done.

> 2. write a bit is much rapider than erase/write sector, right?

Yes, it is faster.

>    so even  I do bit-write operation per one minute, its impact can be
> ignored, right?

Practically speaking, no.  Yes, you can make multiple writes without
an erase, but at some point you need to erase in order to store more
information.  Here is a simple example:

Suppose you need to write a 16-bit value once per minute and further
suppose that the all-ones value (0xffff) is not a valid value.  After
erasing a sector, you can write the first value to the bottom 2 bytes
(assuming 8-bit bytes).  For the next number, if all one bits of the
new number are 1 bits in the previous number ((n1 & ~n0) == 0), you
can overwrite the previous value (free update!).  If false, you can
write the next higher location.  When the sector is full, you need to
start writing a fresh sector, possibly the same one after erasure.

To recover the last value following a power cycle, read the highest
16-bit word that is not 0xffff.

This procedure assumes that you won't get stuck with a value half-way
written.  If that is a possibility, the protocol can be extended to
indicate that the update cycle is complete.  The easiest way is to set
another byte to 0 when the value update is complete, resulting in an
extra byte per value.  This could be optimized to reduce the overhead
by packing bits or taking advantage of data value restrictions.

This technique gives you SectorSize/DataSize writes per erasure,
theoretically extending the number of updates by that factor.  I have
used an enhancement of this technique to give incremental updates to a
set of arrays with infrequent erasures.

Thad

Thad Smith wrote:
> "sailor.gu@gmail.com" wrote:
>
> > 1. As you said, change 1s to 0s need not erase, so it is not a
> > write/erase cycle, right?
>
> Correct, it is only a write.  No erasure is done.

Flash memories are rated 100,000 write cycles, not just erase cycles.

>
> > 2. write a bit is much rapider than erase/write sector, right?
>
> Yes, it is faster.

Yes for EEPROM.  Not necessary true for Flash.

>
> >    so even  I do bit-write operation per one minute, its impact can be
> > ignored, right?

Depends on how the flash is built.  Rather than addressing individual
cells.  Flash controller addresses a block of cells.  There are much
less write amplifiers vs. cells.  You can think of DRAM's row & col
addressing.  Turning on a row will wear out all the cells sharing the
row.

>
> Practically speaking, no.  Yes, you can make multiple writes without
> an erase, but at some point you need to erase in order to store more
> information.  Here is a simple example:
>

For the followings, true for EEPROM, but unknown for Flash.

> Suppose you need to write a 16-bit value once per minute and further
> suppose that the all-ones value (0xffff) is not a valid value.  After
> erasing a sector, you can write the first value to the bottom 2 bytes
> (assuming 8-bit bytes).  For the next number, if all one bits of the
> new number are 1 bits in the previous number ((n1 & ~n0) == 0), you
> can overwrite the previous value (free update!).  If false, you can
> write the next higher location.  When the sector is full, you need to
> start writing a fresh sector, possibly the same one after erasure.
>
> To recover the last value following a power cycle, read the highest
> 16-bit word that is not 0xffff.
>
> This procedure assumes that you won't get stuck with a value half-way
> written.  If that is a possibility, the protocol can be extended to
> indicate that the update cycle is complete.  The easiest way is to set
> another byte to 0 when the value update is complete, resulting in an
> extra byte per value.  This could be optimized to reduce the overhead
> by packing bits or taking advantage of data value restrictions.
>
> This technique gives you SectorSize/DataSize writes per erasure,
> theoretically extending the number of updates by that factor.  I have
> used an enhancement of this technique to give incremental updates to a
> set of arrays with infrequent erasures.
> 
> Thad

I will only account about three days time(4320 minutes).
and I will use 4320bits to recoard the time.
so the erase operation need not be done.
when all bits is set,  no more account action will be done.

linnix wrote:
> Thad Smith wrote:
> 
>>"sailor.gu@gmail.com" wrote:
>>
>>
>>>1. As you said, change 1s to 0s need not erase, so it is not a
>>>write/erase cycle, right?
>>
>>Correct, it is only a write.  No erasure is done.
> 
> 
> Flash memories are rated 100,000 write cycles, not just erase cycles.

Interesting.  Does that mean that using page writes provides N times 
less wear than single byte writes, where both modes are available and N 
is the size of the page?

Thad

"Thad Smith" <ThadSmith@acm.org> wrote in message
news:4305dc6e$0$79779$892e0abb@auth.newsreader.octanews.com...
> linnix wrote:
> > Thad Smith wrote:
> >
> >>"sailor.gu@gmail.com" wrote:
> >>
> >>
> >>>1. As you said, change 1s to 0s need not erase, so it is not a
> >>>write/erase cycle, right?
> >>
> >>Correct, it is only a write.  No erasure is done.
> >
> >
> > Flash memories are rated 100,000 write cycles, not just erase cycles.
>
> Interesting.  Does that mean that using page writes provides N times
> less wear than single byte writes, where both modes are available and N
> is the size of the page?

No. The 100,000 cycles are per cell/bit. Since you can only change a 1 to 0
once and then erase it, that counts as one cycle. Filling a page byte by
byte, with separate write cycles, or doing a page write makes no difference
for each cell, they only get changed from 1 to 0 once. When you erase the
entire page, all cells change to 1 again so the write/erase cycle is
complete. So it's safe to say that 100,000 write cycles is the same as
100,000 page erase cycles.

Meindert

Meindert Sprang wrote:
> "Thad Smith" <ThadSmith@acm.org> wrote in message
> news:4305dc6e$0$79779$892e0abb@auth.newsreader.octanews.com...
> 
>>linnix wrote:
>>
>>>Thad Smith wrote:
>>>
>>>>"sailor.gu@gmail.com" wrote:
>>>>
>>>>>1. As you said, change 1s to 0s need not erase, so it is not a
>>>>>write/erase cycle, right?
>>>>
>>>>Correct, it is only a write.  No erasure is done.
>>>
>>>Flash memories are rated 100,000 write cycles, not just erase cycles.
>>
>>Interesting.  Does that mean that using page writes provides N times
>>less wear than single byte writes, where both modes are available and N
>>is the size of the page?
> 
> No. The 100,000 cycles are per cell/bit. Since you can only change a 1 to 0
> once and then erase it, that counts as one cycle. Filling a page byte by
> byte, with separate write cycles, or doing a page write makes no difference
> for each cell, they only get changed from 1 to 0 once. When you erase the
> entire page, all cells change to 1 again so the write/erase cycle is
> complete. So it's safe to say that 100,000 write cycles is the same as
> 100,000 page erase cycles.

That's what I thought, but linnix wrote:
> 
> Depends on how the flash is built.  Rather than addressing individual
> cells.  Flash controller addresses a block of cells.  There are much
> less write amplifiers vs. cells.  You can think of DRAM's row & col
> addressing.  Turning on a row will wear out all the cells sharing the
> row.

That would argue for page writes, assuming that wrote a single "row" at 
once, as wearing less that individual byte writes.

So the question becomes what is a write cycle for a single cell, as far 
as wearout goes: writing that particular cell or writing any cell on the 
same "row"?

Thad

sailor.gu@gmail.com wrote:

> I will only account about three days time(4320 minutes).
> and I will use 4320bits to recoard the time.
> so the erase operation need not be done.
> when all bits is set,  no more account action will be done.

Sounds straight-forward.

Thad