FLASH; for a given byte address only one write allowed between a page erase yes/no?

[jah]

please confirm the bad news:
for a given flash address, there is only one byte write into flash allowed, then the whole page needs to be erased. no multiple writes to flash allowed unless there is a page erase in between?

refereence a mc9s08rd32dwe at 8mhz

thanks for your help.

[jah]

my bad, thanks everyone.

[tonyp]

With some Flash you can write zero over a previous value and it will work (for example, to mark a record for deletion at a later time).  But, I haven't yet tried this with HCS08 flash.  Anyway, even if this works, it is only good for marking data for deletion (but it saves erase cycles over the life of the product).

Nevertheless, the news isn't really that bad, and it isn't really news, it's been like this for many years with Flash memories.  A possible work-around is described below:

You can allocate an erased 'temp' page to copy the non-affected bytes from the original page along with whatever new data you have.  Then, you can erase the original, and copy the temp over it.  But, this involves two erase cycles and a static 'temp' page that gets written much more often that the remaining pages.

A better solution is something along these lines (many variations are possible):

You can keep a page counter (a byte should be enough in most cases) and a sequence counter (another byte, or at least two bits of the page number if you want to squeeze things and you can fit your page in to two less bits) on the page itself to know which page is which (and what revision), and always erase the previous page with the same page number once you're done copying.  If (due to failure mid-way) when you try to reload a page you find two pages with the same page number, pick the one with the highest revision.  Always write the page/revision data last, i.e., after you're done copying all other page data, so that if a failure leaves a page half-written it will have an erased page/revision, and it can be ignored next time (the older data will be used).  If the failure, happens after a page complete write but before the previous page is erased, the revision will save you.

Page numbers should not be allowed the value $FF (erased state) while revisions can take any value.  Due to possible wrap-around in revision numbering consider $00 as higher than $FF since it is the next possible value during revision incrementing.

Hope this helps.

Message Edited by tonyp on 2006-09-22 12:11 AM

[peg]

Quick answer is:

To make a 1 bit a 0 program it. (a bit at a time if you like)

To make a 0 bit a 1 erase it. (but you need to erase the whole page)

No other choices.

Regards

David

[Alban]

Objection Your Honour.

The "Write more Zeros" tactic, even if possible, is not to be used.

The idea is quite nice I admit but each time there is programming, the High Voltage is put on the whole page to progam the appropriate cell. It 'stresses' the whole page.

For a hobby application, "Write more Zeros" could be acceptable.
In the industry, you have to take into account that it stresses the Flash Array and causes a risk that will be be endorsed by FSL as they forbid it, at least on S08 and S12(X) families.
AFAIB, you should program by FULL ROW (not bit or byte) and erase by PAGE on S08.

Application Notes should be available to emulate EEPROM from Flash. EEPROM emulation gives you a smaller ROW to write.

Alban. (de passage)

[peg]

Hi Alban,

In fact I have never used "writing to FLASH from code within" in an application.

Only used real SPI EEPROM and NOVRAM.

I have only ever written FLASH experimentally.

I am not clear on where the extra stresses comes from using this method.

Also the high voltage is applied to the "array" and not just the 'page"

If the location contains:

11111101

and you subseqently write

11111011

you will get

11111001

how does this cause more stress than erasing then writing?

As I understand it programming a one basically does nothing to a cell, only programming a 0 does anything.

Obviously the number of FLASH writes is still limited.

Regards

David

[Alban]

Hi David,

Yes, the high voltage is available on the whole array. That's why we cannot execute/read code/data from Flash when programming it.

After the whole array is selected, the proper column/line to route this high voltage is then chosen according to the address to be programmed. The presence of this voltage on the programmed area is in itself a stress, probably because of electro-migration.

Reliability issues come from this, that's why Freescale asks the user to always erase before programming again.

When I looked at competitors data I was suprised to see how Freescale data retention and number of cycles were smaller. When I asked for explanation, I was told that Freescale numbers are guaranteed across full temperature range and others are not always...

If you're application stays always at 25C, there is probably a couple of million cycles possible before seeing Flash failure... So I guess that even if Selective Bit Programming is used, you still get a nice number.

However guarantee on the product is lost.

This forbidden method is described on AN2156 (below)

For the initial question, an algorithm like described on AN2186 could ease the pain...

Flash technology and its limitations are quite an interesting subject.

Alban.

--

AN2156
Programming and Erasing FLASH and EEPROM Memories on the MC68HC908AS60A/AZ60A  

AN2186 - AN2156SW
Emulating the HC08AZ60 (or HC08AZ48) Using the HC908AZ60A  

[bigmac]

Hello Alban,

I am confused.  Are you actually saying that the technique described in AN2346 "EEPROM Emulation Using Flash in MC68HC908QY/QT MCUs" is now wrong, and will result in a shortened life for the device?  This AN describes a method where multiple writes are made to a row, without erasure, with the data block size a sub-multiple of the row size.

I seem to recall reading somewhere that there is a maximum accumulated programming time limit that may occur between erasures of each page (I think a figure of about 4ms comes to mind).  The multiple write EEPROM emulation schemes claim to comply with this figure.

I think these issues need to be clarified.

For some of my projects I do store parameter data in flash.  But fortunately, the update frequency required so far is extremely low - a few times in the life of the product - so flash endurance has not been an issue.

Regards,

Mac

[peg]

Hi all,

The mystery deepens.....

I have always taken the statements that you have to erase (a page) before programming flash more as an "idiot proofing" of the instructions than of a technical reason to avoid damage or degradation of the flash.

But the document referenced by Alban (AN2156) suggests otherwise:

In the FLASH section they make the statement (although a little stronger than usual here)

NOTE: To avoid program disturbs, the row must be erased before any byte on
that row is programmed.

Then they devote a section to what they call "Selective bit programming" of the EEPROM with the following statements:

On each programming cycle, one to eight bits of the EEPROM memory
may be programmed. It is possible to program multiple bits at the same
time. However, the same bit may not be programmed twice unless the
entire byte has been erased first. This means that the same byte location
may be programmed eight times as long as an individual bit is not written
to more than once. This is referred to as selective bit programming. The
acceptable sequence in Table 6 shows how the same byte may be used
for eight program cycles without an erase.

EEPROM memory lifetime is guaranteed for 10-K read/write cycles.
However, using selective bit programming extends the life cycle of the
memory 8-fold since each bit is only programmed 10-K times. This
allows the user to program a single byte up to 80-K times.

This is basically what I was suggesting you could do in flash.

So after reading this document you are left feeling like it is a bad idea to prog, prog, prog, erase in flash.

This covers both different bits of a byte and different bytes in a page.

Then along comes Mac quoting AN2346....

In here it says the following:

Although some data sheets discourage writing to a particular row more than once without
erasing it in between, there is no technical reason why this should not be done.
It is also allowable to write to only part of a row at a time, there being in practice
no minimum number of bytes which must be programmed each time a row is
written to.
The only restriction is that the total write time between erases should not
exceed tHV (4ms) per row.

So is this different flash technology or what is the real answer?

Regards

David

[Alban]

Hi guys,

I just read AN2346 and its writer is enjoying some well deserved retirement days. So I can't ask him.

As I believe in the writer's expertise very much, I would be tempted to think you could program more zeros with the HC08. Which is re-assuring for Mac !

On the other hand, the S08 are 0.25µm technology as opposed to HC08 which are 0.65µm or 0.5µm (except HC08AP64 on 0.25µm).
I would not use the program more zeros on S08QG8.

I have never used the S08 SGF drivers, even if I sent them in the past. As they are standard drivers, maybe they handle the programming of one byte and do re-program the rest of the row. This would address concerns of Mac in Post 2951. You can still have "program" in a part of a row for data. the program would be re-written. Not perfectly neat, but you don't waste space.

Cheers,
Alban.

[bigmac]

Hello all,

Application note AN2183 also covers similar ground to AN2346, but for the '908GP32 MCU.  It further supports the case that a row does not have to be fully programmed in a single operation.  The following is a quote from the introduction section of the AN.

Specifications for the M68HC908 Family FLASH memory indicate a program/erase cycle endurance of 10,000 cycles across the full operating temperature range. This is typically more than sufficient for most applications. However, this value can be mathematically elongated by the number of times a small data block can fit within a FLASH erase page.

It is important to note that the while the FLASH memory is "page" erasable, it is, in fact, byte programmable. It’s organization is configured for efficient "row" programming, but any algorithm must write each location on a byte-by-byte basis. There is no limit to the minimum number of bytes that must be programmed within a row. But every time a row is programmed, the high voltage charge pump must be enabled and disabled, regardless of the number of bytes that are programmed.

A critical FLASH memory specification is the cumulative program high voltage period. This is the maximum total time that a specific FLASH program row is subjected to being programmed between erasures. The technical data for the MC68HC908GP32 lists this maximum specification as being 4 ms.

The subroutines herein are optimized to program relatively small blocks of data sequentially within the FLASH memory, thereby minimizing the total cumulative length of time spent programming. These subroutines will only erase the FlashEE space when there is no more room for the next data block. Each FLASH erase page consists of two program rows. The FLASH erase page size for the MC68HC908GP32 is 128 bytes.

With both application notes, the write process is always to unprogrammed locations, so the "programming twice" limitation never occurs.  The only restriction (for HC908 devices at least) would be the cumulative program high voltage period.

I notice that, for HC08 devices, the flash row size will be either 32 or 64 bytes, and the erase block size may vary between 64 and 512 bytes, with the larger block sizes applicable to higher capacity flash memory only.  The smaller capacity devices use the 64 byte block size.

However, for the 9S08 families, the row size is always 64 bytes, and the erase block size 512 bytes, even for devices with 4K and 8K flash, i.e. 9S08QG.  If only a few bytes are needed for non-volatile parameter data,  the 512 block size represents a very significant chunk of memory not available for program code - for the 4K device, one eighth of the available flash.  This might be another limitation for some applications.

Regards,
Mac

[rocco]

And now I'm confused.

---

AN2156 states:
. . . It is possible to program multiple bits at the same time. However, the same bit may not be programmed twice unless the entire byte has been erased first. This means that the same byte location may be programmed eight times as long as an individual bit is not written to more than once. This is referred to as selective bit programming. . .

---

How do you write to a single bit in a byte? What do they mean by "an individual bit is not written to more than once"? As far as I know, you have to write the whole byte, or nothing at all.

Clearly, writing a zero to a bit that was a one would be "programming" that bit.

Is writing a zero to a bit that is already zero "programming" it again? (BCLR instruction! bad!). Do you need to write a one to a bit that is zero to keep from re-programming it?

Or do you have to write a zero to zeros and a one to ones to not program it?

[peg]

Hi Rocco,

The basic concept is.

Never prog a 0 bit twice. If its already 0 put a 1 there in the byte you program.

This of course is of limited use, but could be used as some kind of counter.

This allows you to get 8 writes but only 1 write of wear.

Table 6 and associated text explains this in AN2156 but it is for EEPROM.

Regards

David