FLASH memory write without pre-erase - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 08:42:39 am
content: I am using the Adesto AT45DB321E 4MB FLASH, 512 byte pages.For a particular project, there is a requirement to start with an erased page (all 1s) and then set individual bits down to 0. This is for optimising the 100k write endurance (in a 512 byte page, you can drop a 1 to a 0 with 512x8=8192 writes, but each bit should still see only 1 write for the purpose of reaching the 100k write endurance) and for best resilience for a power failure. The normal (with pre-erase) programming time is 15ms but the without-pre-erase programming time is 3ms.The interface supports writing only whole bytes, and for standardisation reasons I am always writing the whole 512 byte page.It seems to work. This test codeCode:static uint8_t buf;static uint8_t buf2;char buf3;for (int i=0;i<512;i++){buf=0xff;}page_write(0,buf); // test on page 0page_read(0,buf2);sprintf(buf3,"%02x%02x%02x%02x%02x",buf2,buf2,buf2,buf2,buf2);buf3=0;debug_thread_printf("%s",buf3);buf=0x00;buf=0x80;buf=0x01;buf=0xaa;buf=0x55;page_write_NoErase(0,buf);page_read(0,buf2);sprintf(buf3,"%02x%02x%02x%02x%02x",buf2,buf2,buf2,buf2,buf2);debug_thread_printf("%s",buf3);buf=0x10;page_write_NoErase(0,buf);page_read(0,buf2);sprintf(buf3,"%02x%02x%02x%02x%02x",buf2,buf2,buf2,buf2,buf2);debug_thread_printf("%s",buf3);buf=~0x40;page_write_NoErase(0,buf);page_read(0,buf2);sprintf(buf3,"%02x%02x%02x%02x%02x",buf2,buf2,buf2,buf2,buf2);debug_thread_printf("%s",buf3);produces thisCode:ffffffffff008001aa55008000aa55008000aa15which is correct i.e. setting one '1' bit to '0' does work and does not affect other bits.This is how one would expect FLASH/EPROM devices to work, but is it universal? The data sheet is silent on it, and states thiswhich kinda suggests this scheme is not really supposed to work.OTOH EPROM programmers have been doing exactly this ever since we came out of the swampThe raw access functions do allow single byte (not single bit) writing, because the address is a byte-level address and if you just write one byte and then raise CS, that starts the programming cycle after just the one byte, but I am not using that mode; 512 bytes are always written.Any thoughts would be much appreciated.

author: DavidAlfa
author_rank: Super Contributor
timestamp: February 25, 2022, 09:25:29 am
content: I don't know if I understood the question correctly.Those memories aren't like small eeproms where you can accesss individual bytes.Maybe some devices allow individual byte write, but not usual on high density memories, instead, you write pages.The page size is often much smaller than the erase block.You can rewrite a byte without erasing, but you'll be only able to flip 1s to 0s, going backwards requires erasing.Inbany case you still need to write a full page, as defined by the write command.I'd expect having to read the page first, flip the required bits and writing it back.Otherwise, when sending the write command, you might have random data in the buffer.Some memories will automatically fill the internal buffer when selecting the address. Others require a page read operation. Or they might do nothing of this.I think the read buffer would remain unchanged when executing page write, but you'll have to test that.In that case, you could do a pseudo byte-write.Anyways, these specific details can vary a lot between devices.

author: woofy
author_rank: Frequent Contributor
timestamp: February 25, 2022, 09:46:54 am
content: I would advise against this if long time reliability is paramount. It will work in the short time, but there is a risk of over-programming the cells when continually writing 0 to already 0 cells. This can cause the cell to prematurely fail.If you need to do this then do a periodic refresh by reading the page, doing the erase and re-writing it.https://www.embedded.com/flash-101-errors-in-nand-flash/Do you need high endurance for the entire 32Mb, or just a smaller section?

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 09:57:05 am
content: QuoteThat's indeed news to me.However, this device is aNORFLASH. That's a very good article on NOR vs. NAND - thank you.If the cell failed by writing a 0 too often, what would happen?QuoteThat's exactly what I am doing.In practice, the write will be a read-modify-write.The other interesting spinoff of this technique is that in some applications one could dramatically speed up FLASH writing (3ms v. 16ms in this case) by doing a pre-read, and if all 512 bytes are 0xff, do the page programwithoutthe pre-erase. Candidates might be data logging, and anywhere where you can have a background process doing a page erase on pages known to not be in use.

author: woofy
author_rank: Frequent Contributor
timestamp: February 25, 2022, 12:56:47 pm
content: Quote from: peter-h on February 25, 2022, 09:57:05 amOh yes, I do that all the time, except I don't bother reading the page because I know when they are erased. Every time Its needed to cross a sector boundary, ease the sector. Then I can freely write until the next sector without being concerned if the pages are erased. When I come to the end of the allotted sectors I just start over and erase the first one again. For n sectors I have a log n-1 sectors in size.But that's different to writing 0 to already 0 cells.

author: eutectique
author_rank: Frequent Contributor
timestamp: February 25, 2022, 01:40:07 pm
content: Here are two extracts from Ambiq Micro's Apollo2 datashet:NOTEA Flash page size is 8 KB, which is the minimum size that can be erased. An erase cycle will set all the bits in the Flash page to 1’s and bits can be programmed only to a zero state. The same 32-bit word can be programmed a maximum of 4 times, otherwise data corruption or retention issues may appear within the word line. The AmbiqSuite SDK provides a “modify” function to help with this.NOTEThe number of individual word-size programming cycles performed per word line (512 bytes) should be limited to no more than 160 before an erase. Full-line programming of the entire 512-byte word line is faster and less stressful such that programming all 512 bytes in a single transaction counts as only 60 individual writes. Therefore, following a a full-line programming of all 512 bytes, no more than an additional 100 word-programming operations can be performed before an erase is required. Doing more than the specified number of program cycles to the same line before an erase operation may cause data corruption or retention issues within the word line.

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 02:17:44 pm
content: After some searching I found that text herehttps://ambiq.com/wp-content/uploads/2020/10/Apollo2-MCU-Datasheet.pdfon page 141. However I can't find whether this is NAND or NOR FLASH.I have written to Adesto and their new owner Dialog. Doubt they will ever even see the email...The data sheet does not say anything about this, but it ought to if there is a real issue, otherwise why provide the write without pre-erase mode, which is specifically intended for, ahem, writing without a pre-erase

author: eutectique
author_rank: Frequent Contributor
timestamp: February 25, 2022, 03:13:56 pm
content: Ah, I should have given you the exact document name and revision. I've got other docs, "Apollo2 MCU Design Guidelines" and "Apollo2 MCU Errata List", but they do not mention the technology either.But NXP is more specific. Their document "S32K1xx Series Reference Manual" (Document Number: S32K1XXRM, Rev. 13, 04/2020) mentions the following in the section "36.2.3 Glossary":NVM— Nonvolatile memory. A memory technology that maintains stored data during power-off. The flash array is an NVM using NOR-type flash memory technology.Section 36.2 has the following:CAUTIONA flash memory location must be in the erased state before being programmed. Cumulative programming of bits (back-to-back program operations without an intervening erase) within a flash memory location is not allowed. Re-programming of existing 0s to 0 is not allowed as this overstresses the device.Though they do not specify explicitly what "flash memory location" is -- a byte? a word? 4 words? -- they mention it in context of 128 or 64 bits, depending on the flash bank.But again, that's yet another vendor with another implementation.

author: woofy
author_rank: Frequent Contributor
timestamp: February 25, 2022, 03:15:05 pm
content: Quote from: peter-h on February 25, 2022, 02:17:44 pmThe AT45DB321E has Page, Block Sector and Chip erase commands. If you have done a sector erase there is no need to do it again for each page.The page erase time is 17mS, whereas the sector erase time is 700mS for up to 128 pages. That would be over 2 seconds if done on a page basis.Chip ease isn't faster than the sum of the sector times because the chip can only erase 1 sector at a time - it cycles through them.

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 03:25:28 pm
content: QuoteI find that very hard to believe, taken literally.QuoteIn normal use, I only ever do a page (512 bytes) writewiththe pre-erase. This is rock solid, running on a number of boards for about a year. Not going anywhere near the 100k documented write endurance though.I am not using any sector commands, chip erase, etc.In the proposed usage mode (notusing pre-erase and just using RMW to drop 1s to 0s, one bit at a time) there will be at most 8192 writes to a given page. This is because each bit signifies that a page elsewhere on the device has failed to verify, and needs to be skipped.In fact the max # of writes will be 1023 since the area of the device being used for this purpose is only 512k. So, I suppose, we could just use the normal mode (withpre-erase) for this, since 1k is well short of the 100k endurance. But that gives a reduced resistance to power failure.The email to Adesto bounced back.Looking at the NXP stuff, I see e.g. thishttps://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-K10FX512-read-flash-hard-fault/m-p/439234which saysYou are not respecting the phrase programming requirements fo the Flash in the K10FX512.You are only allowed to write 8 byte blocks at at time (phrase) and any attempt to write to one of these phrases (8 byte blocks) that is not erased will corrupt the Flash and cause it to return a hard fault afterwards (it then requires an erase to recover).but this is clearly a different architecture to Adesto, which explicitly does allow (by means of direct byte addressing) random writing of bytes within the 512 byte page.

author: woofy
author_rank: Frequent Contributor
timestamp: February 25, 2022, 03:52:21 pm
content: Ah, I see what you are aiming to do now. As always, there are many ways things can be done.I think in this case I would just include a CRC in the extra 16 bytes each page has and forget the bit mapping.One of the tricks I do to mitigate power failures is to monitor the incoming voltage before reservoir caps and regulation, then I only start the write if there isn't a power fail in progress and I know there is power to complete the write.

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 03:56:52 pm
content: Ahayes... unfortunately I am not using the 528 byte page size mode, for various reasons (other areas of the chip, the possibility of changing it one day for another FLASH device, etc). I posted a thread on this topic here a while ago.Unless Adesto confirm the proposed usage is ok, it may be safer to use the pre-erase mode.

author: Cerebus
author_rank: Super Contributor
timestamp: February 25, 2022, 04:23:50 pm
content: Quote from: peter-h on February 25, 2022, 03:25:28 pmThe storage device is a single MOSFET. The gate of that MOSFET is floating, insulated from everything, there is no electrical connection to it. Programming the device is done by bringing an adjacent electrode to a sufficiently high voltage that electrons will tunnel through the insulator surrounding the gate and leave a charge on the floating gate. That involves very high voltage gradients. It may be a small voltage in absolute terms, but it's across structures measured in nanometers, so in terms of volts/metre the field strength is huge, on the close order of 500megavolts per metre.I don't think it's hard to see how exceeding the breakdown voltage of the gate oxide would stress the device, and doing it too many times would overstress the device.

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 04:44:53 pm
content: OK; no matter how this is looked at, all this stuff seems to be very device dependent.For example Adesto have this paragraphwhich shows a different kind of "weakness". In practice it means the ensurance is not 100k but 50k - because there is no practical way to keep track of which pages havenotbeen reprogrammed for a long time.And using say a verify-after-program or a CRC or whatever is no defence against this, because you could be corrupting a page which has not been accessed for ages and which you have no reason toperiodically examine. For example you could have a 1MB area for data logging, and a page for device config data, and then one day you find the config page has changed.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 25, 2022, 05:21:25 pm
content: Quote from: peter-h on February 25, 2022, 03:25:28 pmYet, it's implied in one form or another in almost all flash and MCU datasheets.The classic mental model "erase sets to 1, write sets to 0" is insufficient. People should actually read the datasheets. They almost always completely forbid repeated writes to the same words (i.e., max number of writes = 1), or specify a fairly low number. I have seen 2 and 4 max writes specified.If some particular datasheet fails to discuss this at all, I would be cautious about it, unless they really market their flash as something that is better than their competitors in this regard.From user viewpoint, the exact mechanism doesn't matter. It's forbidden or warned against - don't do it.

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 05:34:18 pm
content: Interesting - many thanks. So I will abandon the no-pre-erase mode. It seems useful just for asinglewrite, and only when you somehowknowthe page was previously erased.I found thishttps://www.dialog-semiconductor.com/products/memory/dataflash-spi-memory#tab-field_tab_content_resourceshttps://www.dialog-semiconductor.com/sites/default/files/an500.pdfwhich is quite interesting.There is another appnote called AN-4 (“Using Adesto’s Serial DataFlash”) which is referenced in various Adesto/Atmel data sheets but which I can't find.BUT: While I think we can say that on info currently known this approach isn't suitable for repeated writesof 0 with 0. But what if you write a0 with a 1? It will still be a 0 afterwardsThis is for the scenario where you have a byte of say 00000001 and you want to make it 00000000, so you write 11111110. What is wrong with that, physically, in the silicon?

author: woofy
author_rank: Frequent Contributor
timestamp: February 25, 2022, 06:04:52 pm
content: Quote from: peter-h on February 25, 2022, 05:34:18 pmI imagine it will generate a write fail error. To quote the datasheet (page 10):"The device also incorporates an intelligent erase and program algorithm that can detect when a byte location fails toerase or program properly. If an erase or programming error arises, it will be indicated by the EPE bit in the StatusRegister."

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 06:11:08 pm
content: Oh sure but I never check that bitI probably should, but it leads to the "usual embedded system question" of what do you do about a (normal) FLASH write error? Flash (no pun intended) some LED with an error code, or if you have an LCD you display a URL to the mfg's online shopIf I was implementing verification, I would just read the page and compare. It is very fast, zero time really compared to the milliseconds of program cycles.In myCPUFLASH programming code, this is all done differently. I pre-test the uppermost 128k (which on the 32F417 is a single sector for erase purposes) with some data, and proceed only if this verifies. 2 or 3 retries. Then program the rest, again with retries.

author: eutectique
author_rank: Frequent Contributor
timestamp: February 25, 2022, 08:05:51 pm
content: QuoteArmaments, Chapter 2, Verses 9 to 21S32K1xx Series Reference Manual, Chapter 36:QuoteThe target market is automotive, hence the extended wording.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 25, 2022, 08:39:20 pm
content: Quote from: peter-h on February 25, 2022, 02:17:44 pmDialog's new owner is Renesas -- maybe you should write to them.

author: peter-h
author_rank: Super Contributor
timestamp: February 25, 2022, 08:51:48 pm
content: QuoteThat is consistent with my understanding of "EPROM" type devices, which all have the same issues with the voltages drifting around over time, and the read detector thresholds have to be carefully chosen.Unfortunately it doesn't illuminate the "write a 0 with a 1 being allright" proposition, which would solve the requirement of setting just say 1 bit in a 512-byte page to a 0. You would pre-read the page to make sure the bit in question is not already 0, and then write 512 bytes of 1s, except that one bit.QuoteGot an email address?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 26, 2022, 08:45:17 am
content: It was totally ok to write 0s bit by bit into devices like 28F800 era. Vendor libraries (i.e. Intel’s FDI) were doing that. I see no reasons why the write state machine couldn’t detect already zeroed bits and gate them off before sending HV pulses (the same way as bits with 1 new value are gated off). They are complex enough i.e. to automatically write all cells of a sector to 0 before erasing. The question is how is it implemented in a particular device.

author: peter-h
author_rank: Super Contributor
timestamp: February 26, 2022, 09:17:38 am
content: The Adesto chip has another, quite nasty, issue, which I have documented as follows:Corruption of other pages within a sectorThe AT45DB321 device has 512 byte pages but underlying that are 64k blocks, called “sectors”. I am not making any use of this sector architecture. The gotcha is that once the total number of writes to a given sector (anywhere within it) exceeds about 50000, subsequent writes within that sector can flip bits elsewhere in the sector! The bits or bytes which might get flipped are ones which have not been reprogrammed (refreshed), so a page holding static data could get corrupted as a result of writes elsewhere within that sector. To guard against this, you have to periodically refresh (read, and write back with pre-erase) pages which are static (rarely used) if there is a lot of write activity elsewhere in that sector. And 50k writes within a 64k sector is not a lot of writing, and is well below the 100k “headline” endurance of the device. All you need to reach that 50k value is write each page in the sector 781 times.One solution would be an RTOS thread which slowly walks along the FLASH and rewrites it page by page, but a simple implementation would be dumb because that alone would reach 100k/page eventually, and any counter scheme will itself wear out the page. And this thread will create a vulnerability with a power failure.Fortunately in my project it should work because the memory map was "accidentally" chosen so that one doesn't have frequently written data and static data within the same sector.

author: WatchfulEye
author_rank: Regular Contributor
timestamp: February 26, 2022, 12:16:07 pm
content: "Write disturbance" is an issue common to all flash memory. A write operation on a page degrades the SNR of data stored in the page and in nearby pages (i.e. within the same sector).You are unlikely to hit problems if you avoid operations not specified in the datasheet (e.g. not reprogramming an already programmed byte in byte-programmable NOR) or you stay within the maximum number of partial page writes if this is explicitly specified (can be as low as 2 in high density NAND flash). However, picking off individual bits in a sector, is exactly the sort of use case where write disturbance could be a problem. As this is essentially a noise/threshold problem, it may only become apparent under adverse conditions (e.g. flash wear, voltage or temperature extremes, etc.)

author: DavidAlfa
author_rank: Super Contributor
timestamp: February 26, 2022, 12:30:40 pm
content: I knew write distrurbance existed, so ex. you must rewrite nearby cells after some write cycles, in modern flash this is ususally automatically handled by the controller.But didn't know that writing 0 to already 0 bits could cause premature damage or wear!

author: Peabody
author_rank: Super Contributor
timestamp: February 26, 2022, 04:03:26 pm
content: Would you consider using something other than flash? Nothing else would be as cheap, but it seems FRAM or battery-backed SRAM might perform better for what you're doing. Not sure you would find anything at 4MB though.

author: peter-h
author_rank: Super Contributor
timestamp: February 26, 2022, 06:15:37 pm
content: QuoteThe Adesto data sheet (and actually the data sheets for the same ATxxxx devices, under the Atmel or Microchip brand) document this issue, with some limiting the sector total page write to as little as 10k. But none say anything about "nearby" cells; the affected cell can be anywhere within the same sector.If you can be sure you always have power, or you have a rock solid power fail detection giving you a margin of > 20ms, then the solution is fairly easy to implement: whenever you write a page, you set a "this sector needs a refresh" flag. That flag can probably be in RAM, because it doesn't really matter if you don't get around to it the 1st time. Or you could have a proper counter in RAM, and when it reaches say 10k, increment a count in FLASH. Then you have an RTOS task which runs when that FLASH write count reaches 5 and which refreshes that whole sector. Or some smarter variation...The funny thing is that these chips have another 16 bytes per page, which can obviously be used for counters and such, but the data sheet doesn't give you any hint on how to do it intelligently. Have lots of people solved this independently, or maybe nobody bothers? It is quite possible that in most applications one gets away with it, by accident.QuoteFRAM is expensive, and poorly multi-sourced. Battery backed SRAM is a really big problem because of poor battery options. I have been doing that for decades; the basic problem is that all the batteries which have a long functional life (decades) are primary (and you can get maybe 20 years before they fail into a short circuit), and the rechargeable ones have a poor life. This product has to work for > 20 years. I already have a 0.22F supercap on the RTC (which is inside the 32F417) and that runs for about 3 days which is OK for the application.

author: DavidAlfa
author_rank: Super Contributor
timestamp: February 26, 2022, 07:44:37 pm
content: Oops, what I had read was for MLC flash.Anyways, it was read disturbance, not nearby-cells-anythinghttps://users.ece.cmu.edu/~omutlu/pub/flash-read-disturb-errors_dsn15.pdfWhat about a low power sram or sdram + supercap?Some chips have a retention-only ultra low power state.And a 1F supercapacitor isn't that expensive anymore?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: February 27, 2022, 08:25:01 am
content: Quote from: peter-h on February 25, 2022, 05:34:18 pmIt should be easy to try that, and it seems a good and simple idea to avoid potential issues.I think one failure mechanism of multiple 0 writes ischarge bubble overflow into adjacent bits, so you could program a checker board pattern and use your zero mask on one half, and skip the zero mask on the other half, and then thrash it for a day or two, and see if any 1's ever read 0 unexpectedly.The HWmaybe smart enough to avoid multiple zero write attempts, but I'm not sure how you'd prove that ? maybe record the program time via polling ?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 27, 2022, 01:10:58 pm
content: I thought about comparing programming times for 1->0 and 0->0 cases too, but this would prove nothing I guess: internal programming algorithms are iterative (pretty same as algos applied externally on 27xx series) - give a HV pulse, read back, compare, repeat if doesn’t match, give some more "finalizing" pulses to move further from the margin, end. So in both cases (with prior 0 detection and without) 0->0 should be faster.

author: peter-h
author_rank: Super Contributor
timestamp: February 27, 2022, 04:10:51 pm
content: 0 to 0 should program very fast if the state machine skips such bits, but it is probably byte-wide so it doesn't have the opportunity to do so.The adjacent line disturbance is a bigger problem. I think I will implement some page write counters, pne per sector, in RAM and when any gets to say 1000, increment a corresponding counter in FLASH.When that counter gets to 50, an RTOS task can be triggered which refreshes that whole sector. The problem is that the exec time for that is 2 seconds! So it will need to be spread out. It's a crappy solution really... but at least the risk is zero until 50k writes in any sector is reached, which will probably never happen in most applications, which is probably how these devices manage to be used successfully