What's NOPs of NAND
in [Embedded]
|
Prev: PowerPC books ARM
Next: crc32 calculation
From: Stefan Reuther on 31 Mar 2010 13:30 Marc Jet wrote: > When you erase and programm a page, everything is fine. But if you re- > program it (without erasing), then the previous information "suffers" > a little bit. It's still in good shape when you do that once or > twice. But it's definetly not reliable anymore if you do it more than > 8 times. You will get lots of read errors. Plus, even in the "good" case, you cannot program a single cell twice. All partial programs should go into disjoint areas of a page. > A page is usually just 512 bytes, so you probably won't need to > partial-program it often. The normal approach is to write new > information to new pages. For devices of decent size, the page size is now 2048 or even 4096 bytes. In any case, if you do extensive partial page programming, even if you're not exceeding NOP, you will get more bit errors than if you don't. I use it when I have to, but otherwise try to avoid it (by combining partial page writes at the application side). Stefan
From: kaimi on 1 Apr 2010 03:06 >>Marc Jet wrote: >> When you erase and programm a page, everything is fine. But if you re- >> program it (without erasing), then the previous information "suffers" >> a little bit. It's still in good shape when you do that once or >> twice. But it's definetly not reliable anymore if you do it more than >> 8 times. You will get lots of read errors. >Stefan wrote: >Plus, even in the "good" case, you cannot program a single cell twice. >All partial programs should go into disjoint areas of a page. When I combine 2 info: "you can re-program a page without erasing it NOP times" and "you cannot program a single cell twice", I come up with: I can do a re-programming, which is turning bit 1 to 0 and not vice versa (Stefan, is this implied in the "disjoint areas of page" you said?), into an already programmed page no more than NOP times. Do I get it right? If so, I feel that "if you wait long between writes, it becomes less writeable until you cannot write to it anymore" Dijkstra said makes some sense now. Is it like if I re-program some data on a page at a time then whole re-programming is counted as 1 NOP, but if I wait for awhile and do another re-programming then it is counted as another NOP. >>Marc Jet wrote: >>Partial programming is useful when you create a journalled >>filesystem. Often you want to write only a small amount of data. If >>the data fits into the "current" page (and the page has not yet been >>written 8 times), then it can be appended using a partial write. And in practical uses, one like the above case, a re-programming is actually done in the not-yet-programmed area of a page, right? If the data to be written fits into the "empty" area of a page, right? I can't think of a situation where new data (to be programmed) has bit pattern that is only different in bit 1 comparing with the old data in flash. Or partial-re-programming in NAND flash can really turns bit 0 back to 1, just not more than NOP times? >Stefan wrote: >In any case, if you do extensive partial page programming, even if >you're not exceeding NOP, you will get more bit errors than if you >don't. I use it when I have to, but otherwise try to avoid it (by >combining partial page writes at the application side). Does that mean NOP from NAND spec is not reliable? In a system like Linux, is NOP caring handled at NAND flash driver level? at filesystem level? and I doubt at application level? Could you share how you handle it? --------------------------------------- Posted through http://www.EmbeddedRelated.com
From: Boudewijn Dijkstra on 1 Apr 2010 03:30 Op Wed, 31 Mar 2010 17:43:58 +0200 schreef <Anders.Montonen(a)kapsi.spam.stop.fi.invalid>: > kaimi <kaimi2005(a)n_o_s_p_a_m.yahoo.com> wrote: >>> They are talking about _partial_ programming, a.k.a. programming _on_ a >>> page. After a page is erased, it becomes writeable, but if you wait >>> long between writes, it becomes less writeable until you cannot write >>> to it >>> anymore. >> I think "number of times", not "how long between each times" was >> mentioned in the FAQ. It complicates my not-understanding now ;) > > I think they mean that after partially programming a page NOP times the > whole page must be reprogrammed or the data may be corrupted. I must admit I got confused a bit as well because they didn't mention anything about the cell level. I was assuming that it takes more than NOP machine writes to fill a page, which would make it impossible to fill the page if you read the text literally. I will leave it to the experts to lift the confusion. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail)
From: Stefan Reuther on 1 Apr 2010 13:03 kaimi wrote: >>>Marc Jet wrote: >>>When you erase and programm a page, everything is fine. But if you re- >>>program it (without erasing), then the previous information "suffers" >>>a little bit. It's still in good shape when you do that once or >>>twice. But it's definetly not reliable anymore if you do it more than >>>8 times. You will get lots of read errors. > >>Stefan wrote: >>Plus, even in the "good" case, you cannot program a single cell twice. >>All partial programs should go into disjoint areas of a page. > > When I combine 2 info: "you can re-program a page without erasing it NOP > times" and "you cannot program a single cell twice", I come up with: I can > do a re-programming, which is turning bit 1 to 0 and not vice versa > (Stefan, is this implied in the "disjoint areas of page" you said?), into > an already programmed page no more than NOP times. Do I get it right? Yes. > If > so, I feel that "if you wait long between writes, it becomes less writeable > until you cannot write to it anymore" Dijkstra said makes some sense now. > Is it like if I re-program some data on a page at a time then whole > re-programming is counted as 1 NOP, but if I wait for awhile and do another > re-programming then it is counted as another NOP. Other than normal "charge loss", it doesn't matter whether you're doing your 4 partial programs within a second or a week. >>>Marc Jet wrote: >>>Partial programming is useful when you create a journalled >>>filesystem. Often you want to write only a small amount of data. If >>>the data fits into the "current" page (and the page has not yet been >>>written 8 times), then it can be appended using a partial write. > > And in practical uses, one like the above case, a re-programming is > actually done in the not-yet-programmed area of a page, right? If the data > to be written fits into the "empty" area of a page, right? I can't think of > a situation where new data (to be programmed) has bit pattern that is only > different in bit 1 comparing with the old data in flash. The practical uses I've seen so far split pages evenly into partial pages. A scheme that stores a bit array and successively turns 1 bits into 0's isn't so practical with NAND flash anyway. It's very practical with NOR flash, to manage allocation tables etc. But for NAND flash, you have to keep track of NOP anyway. You cannot distinguish a half-written page that has been written in one operation from one that has been written in four. > Or partial-re-programming in NAND flash can really turns bit 0 back to > 1, just not more than NOP times? In the parts I've seen, you can only turn 1's into 0's. >>Stefan wrote: >>In any case, if you do extensive partial page programming, even if >>you're not exceeding NOP, you will get more bit errors than if you >>don't. I use it when I have to, but otherwise try to avoid it (by >>combining partial page writes at the application side). > > Does that mean NOP from NAND spec is not reliable? In a system like Linux, > is NOP caring handled at NAND flash driver level? at filesystem level? and > I doubt at application level? NOP is as reliable as the speed limit of your car. The car can go 170 km/h, but it won't get better if you do it all the time. The same goes for NAND flash. You can write four times, but you will get more bit errors, so you'll be closer to the edge of what your ECC can handle. It'll still work, but you'll have fewer reserves. > Could you share how you handle it? I use a fixed split (one page = NOP partial pages), but I try to avoid reaching the NOP limit by combining partial page writes. Most of the time, I need just one or two writes per page. Stefan
From: Marc Jet on 9 Apr 2010 06:47
kaimi wrote: > >>Marc Jet wrote: > >>Partial programming is useful when you create a journalled > >>filesystem. Often you want to write only a small amount of data. If > >>the data fits into the "current" page (and the page has not yet been > >>written 8 times), then it can be appended using a partial write. > > And in practical uses, one like the above case, a re-programming is > actually done in the not-yet-programmed area of a page, right? If the data > to be written fits into the "empty" area of a page, right? I can't think of > a situation where new data (to be programmed) has bit pattern that is only > different in bit 1 comparing with the old data in flash. Or > partial-re-programming in NAND flash can really turns bit 0 back to 1, just > not more than NOP times? A partial write can only ever change a 1 to 0. As Stefan has pointed out correctly, many flash devices forbid programming a bit twice (without erase cycle). Your strategy for partial writes should be to fill a page-sized RAM buffer with 1 bits. Then insert the data that you want to append in your partial write, into yet unwritten bit locations. Then write the whole page. The flash device will merge the existing page content with the appended content. The trick is to keep track of which bit locations have been written already, and which didn't. One way comes to mind immediately - that of reading the page and checking for 0-bits. However that isn't always reliable, because maybe a partial write has been interrupted by a power failure. Then the bits are not prestine anymore, yet a page read may STILL return them as 1. This spoiling the approach of checking for unused bits by reading. Best regards |