Program FLASH more than once after erase

[OldMan]

I am kind of green with Freescale micros. I have two somewhat related questions.

(1) My experience with Flash memory from other sources is that you are allowed to program a byte multiple times after erase. Each attempt cannot change any bit from 0 into 1. But you can leave any bit unchanged or change 1 into 0. An erased byte is $FF. For example, you can program it into $FE and subsequently, program the $FE into $FC. But you cannot change $FE into $FF or $FD without first erasing (the page containing) that byte.

Freescale “MC9S08QG8 and MC9S08QG4 Data Sheet, Rev. 1.01” Section 4.5.3 “Program and Erase Command Execution” (on age 45) says”

“NOTE

“Do not program any byte in the FLASH more than once after a successful erase operation. Reprogramming bits to a byte that is already programmed is not allowed without first erasing the page in which the byte resides or mass erasing the entire FLASH memory. Programming without first erasing may disturb data stored in the FLASH.”

Is this a Freescale canonical rule?

(2) When my code does not specify a value for NVOPT, CW5.1/P&E automatically programs the value $FE to Flash byte at $FFBF (NVOPT). When my code specifically sets NVOPT to be DC.B $FC, CW5.1/P&E programs that value correctly too. However, if my code sets NVOPT to be DC.B $FF or $FD, CW5.1/P&E always reports a “Programming and Verifying Address $FFBF Error”.

This seems to indicate that after erase, CW5.1/P&E always program $FFBF into $FE. If my code specifies a value for NVOPT, CW5.1/P&E tries to program the same byte again without erasing it first.

Is my deduction correct? Is CW5.1/P&E violating the rule: “Do not program any byte in the FLASH more than once after a successful erase operation”? Will CW5.1/P&E “disturb data stored in the FLASH”?

[peg]

Hi OldMan,

You have to remember that the Freescale guys that do the specs live in a big plastic bubble. (Wouldn't want to go outside "It's dangerous out there")

Seriously though, they err on the very safe side of everything. Which is a good thing but can bring with it some little white lies as well.

Refer to these threads:

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=3649

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=2922

There are many others as well if you can put up with the pathetic excuse for a search engine we have here.

Regards

Peg

After reading your question again I see that really you already know the answer. Also the NVOPT reg is progged to $FE at the end of the erase process.

Message Edited by peg on 2007-01-2209:04 PM

[Alban]

Hi Oldman & Peg,

It is because of the Flash technology that this "programming more zeros" method is not to be used anymore. On older Flash, it was acceptable and done.

AFAIK Freescale is using licensed Flash technology and not their own idea.

About the risk, I do agree with the bubble to a certain extent: most of the product will end up in Automotive where Safety is critical. Car manufacturers and Customers would not be delighted if the brakes stopped working because the bubble wasn't big enough at the start .

But if you do a toy to sell on the market without any warranty, you can probably do whatever you wish

Peg,

Google can also be used to search Freescale Communities as they crawl the site daily !

But the internal search engine does give me satisfactory replies... I must have low standards then

Cheers,

Alban.

[peg]

Hi Alban,

If "multi" programming of a byte is so bad then why does Freescales own product (Codewarrior) provide no other means for securing a part than to multi programme the NVOPT register?

Regards

Peg

Sorry rant mode doesn't seem to want to go off. Maybe  I programme it too many times without first erasing

[Alban]

Hi,

First, I think I need to stress again that P&E Microcomputer Systems is not owned or ran by Freescale Semiconductor.
CodeWarrior is owned and made by Freescale and include third party software.

If you think the third party package is not suitable for you, feel free to change it.

But before doing this, the user needs to think about the risk of maybe corrupting ONE bit in ONE byte READ only ONCE after reset, compared to WRITE EIGHT times in ONE byte that is read/WRITTEN HUNDRED times in the application.
On one hand, worse come to the worse, the part would still be secured. On the other hand, you just have a application crash/fire and/or injury/death of the user.

And, before someone comes with the "yeah, but when my car is broken, I bring it to the dealer and I don't care about what part fail"... If you add a DVD player/Phone holder/CB, the dealer won't have much power.

Warm Regards,
Alban.

[peg]

**bleep**, I nearly got out of bed to restructure my question when I realised this cop out would be the answer. Too late!

P.S. I am well aware they are seperate companys, in fact I don't use Codewarrior but ONLY P&E's tools for my professional work. For me Codewarrior is a massive wrapper around P&E's tools which only serves to limit their functionality. But it makes them free

Regards

Peg

[mke_et]

I do it all the time. In fact, standard FLASH management almost REQUIRES that you do it. I use it to invalidate areas of FLASH so that my program can pick up NEW variables further along in the memory.

What I do is divide my FLASH into 'FRAMES'. Each frame has a descriptor at the head end, and then data which starts with the size. As data is changed. I don't want to pound a small area of FLASH to death, even if it IS the size of an erase block, so I 'invalidate' it by changing changing the descriptor to 00. I look for the first free area to build a copy of the frame with the new values and place it there. The program then only needs to walk the FLASH looking for the descriptor, then set the index there. Then if I run out of FLASH, I then 'recover' by bulk erasing, putting the new descriptor blocks at the front end, and starting all over.

I know, it's not quite FFS1 or FFS2, but it works... And the 'wear leveling' advantage I get is worth any degredation from 'double writes', which is probably an 'edict' anyway and not a real technical concern.

I wonder, IS there any real technical concern here? Or is it just a holdover from the original type 1 FLASH chips that had no protection from slamming the rails and could hose the chip? Once the state machines were used in the second type FLASH chips, all the worries of that sort went away. Except for the people who didn't understand the problem, knew there was a problem somewhere at some time, and though it applied to everything.

Mike

Message Edited by mke_et on 2007-01-2206:51 PM

[OldMan]

Quote from documents about "cumulative program time" of a different FLASH based micro from a different company:

“Each time a single bit, byte, or word is programmed, a complete row of 64-byte flash cells sees the high voltage necessary for programming. This high voltage generates some stress to the complete row of flash cells, and this stress must be time limited to avoid damage. The next erase cycle resets this stress time to zero, and the cumulative program time restarts again from the beginning. According to the data sheet, as shown in Table 3 (omitted), this high-voltage stress must be limited to 10 ms between two erase cycles. See the data sheets for the correct values for each MSP430 derivative.

“The same 16-bit flash word cannot be programmed more than twice before the next erase cycle. Writing to one 16-bit word with two byte-wise programming cycles counts as two programming cycles. Single-bit over programming is possible only once, if the flash cell previously has been programmed 16-bit word wise.

“Writing to the same row too many times may result in write disturb, and erased bits will be programmed as well. This produces no physical damage and, after erase, the disturbed bits are programmable as before. No long-term effects are known.”

I do not know if the above is correct or not. I also do not know if Freescale FLASH are different or not. But at least the the above quote sounds more like a technical document and not a cardinal law from the church.

[Alban]

Hello,

Please refer or cite official documents like

(September 2006) http://focus.ti.com/lit/an/slaa334/slaa334.pdf 

which DOES mention limitations to overprogramming !

If you put charges in a floating gate, you also need to remove them.

With time, these charges will be more and more difficult to move and the level will be less and less delimited until one day a bit starts flipping.

High voltage is a stress for the Flash array and another limitation as clearly stated in the document.

If you put less charges, the level will stay correct for a shorter lenght of time because of leakage of the floating gate.

These are not "cardinal laws" from any body but Physics.

Please do feel free to look at the Engineering Bulletins detailing how Freescale calculate their specified values if you want to compare. I will not compare as I don't intend to use the MSP430.

Alban.

[Nabla69]

Hello,

It's getting quite burning on this thread...

I don't see why Freescale would put a limit by pure pleasure anyway.
Even if the reason could be difficult to understand, it has to have a real technical reason.

I think the interest of any company is to spec their devices as competitive as they can, but it needs to be true.

Going over the specified limit is likely to work, as usual, but how long ?
Freescale only test within specification and slightly above...
-----> Fair enough, I imagine a few Zillions of cases to test otherwise.

If the user wants to use it out of spec, he is free to do so... But he has to assume consequences.

I have another input to avoid overprogramming: use some the of Flash with drivers Flash as EEPROM, when a byte/bit is written, the driver will handle the row erase and other bytes reprogramming.
Also, another way is to have an algorithm looking for the last written value in a zone.
This is when you use the system described by Mike_ET just few posts above. Values authorized would be between 0x00 and 0xFE and when there is an 0xFF, it is an empty zone.
This way, you can program each byte, one at a time and only erase the row(s) once, when you arrive at the end of delimited space.

It does work.

My 2 cents.
Alvin.

[mke_et]

First off, I didn't mean to come on so strong, so let me expand a bit on my comments.

There HAS to be a way to invalidate an area of flash that is independant of the size of the erase block or the usefullness of the part for 'data storage' is severely crimped in a practical sense. To do that implies multiple writes (zero going) are allowed. I can't recall any data management scheme that would work without that feature.

Now, there are multiple technologies, and the issue was raise that Freescale acquired the flash technology they use, so that brings up the question is the limitation a real practical limitation or is it something that just sort or got passed through many hands and is now accepted as fact?

I've written FFS1 and FFS2 low level ( 'MTD' ) drivers when I was with another company, and I've never heard before of the limitation on multiple zero writes. In fact, with early flash (Intel Series 1 and 'workalikes') it was RECOMMENDED that they be 'bashed into the ground' with multiple writes to zero to insure that they had as close to a consistant zero starting point for erasure as possible. Then when you did the timed erase you didn't run the risk of cells coming up unevenly. The danger being a cell that went 'over the top' and now wouldn't erase. The analogy was you had to empty all the cups of water so that the 'timed' fill (erasure) of them all would be correct. If one still had water in it, it would overflow on filling and ruin the cup.

I'm not saying there isn't a technical issue with multiple writes to zero, but from all I've been exposed to in the past, the 'wear and tear' of the writes to zero was FAR less than any stress induced by erasures.

Unfortunately, I HAVE heard unsubstatiated recomendations about how to write to flash in the past, from otherwise respectable sources, but I've never seen a good 'technical' reason as to why it should be so. That's why in this case, I really would like to see info all the way back to the cell design as to why multiple writes to zero aren't recomended.

Mike

[Alban]

Dear Mike,

To invalidate you can write more zeros safely as you don't want to use the cells info but want to "disable" it. In the normal process of these Flash wearing, you could have the descriptors in RAM as mentioned by Nabla69. Actually, a similar principle is used in the new S12XE EEEPROM (Emulated E²PROM). (Yes, that's 3 Es...)

I know that Freescale did extensive research/tests in the Flash they are using.

That is why they can proudly announce very low defectivity in the S12 family altogether

As far as I know tests were revealing a lower number of cycles when doing overprogramming.

May you please explain to me FFS1 and 2 and MTD terms ? I am not familiar with these.

At the time of old Flash, the retention was much shorter, so leaks much higher. As the technology was may be larger, there was less impact on the floating gates life. I am just supposing here.

I will try to dig information from Freescale NVM Guru I know. Depending on the sensitivity of the information, I may not be able to get and/or post much. Processes are Confidential in all companies.

As far as I understood, the "writting more zeros" is not necessarily a stress on a certain flash cell, but can be on the row getting the high voltage from the charge pump.

I don't promise more information than I already explained.

Alban.

[mke_et]

Hi Alban

FFS1 and FFS2 were the 'Flash File System' specs from years ago. FFS1 was essentially a 'worm' (write once, read many) flavored operation that invalidated areas and went to new areas. As the system ran out of resources, then you needed to have an external 'recover' utility. The original sectored CD file system was pretty much the same way. FFS2 was designed to be an 'active internal' recovery type system, and is what was used on most PCMCIA flash cards. This kept all the internals of operation hidden, and from the OS point of view the flash card appeared as FAT media. In fact, a lot of utilities that used 'int 13' to access sectors would even work. (Well, depending on who wrote the driver!)

MTD is the low level Memory Technology Driver that interfaces to the flash. It's how you talk to a card without knowing (or even caring) what the card is.

In the early days of PCMCIA the MTD is what did all the work to the card. You loaded a stack of MTDs for the types of cards you intended to use, and now you had read/write access to all the cards. If you didn't load a specific MTD, you could still use a generic SRAM type MTD to read the card, but you couldn't write to it.

Mike