FreeCalypso > hg > freecalypso-tools
diff doc/How-flash-really-works @ 1000:39a6090a052a
doc/How-flash-really-works: article written
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 09 Dec 2023 09:08:19 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/How-flash-really-works Sat Dec 09 09:08:19 2023 +0000 @@ -0,0 +1,97 @@ +How NOR flash memory really works +================================= + +The type of flash memory used in Calypso GSM devices is formally known as NOR +flash. Most embedded software programmers and tinkerers know the fundamental +principle of how NOR flash works: any bit can be transitioned from a '1' to a +'0' at any time in any combination (an operation called programming), but the +opposite transition (from '0' to '1' bits, an operation called erasure) can only +be done on fairly large sectors - you can erase a sector and make it all 1s, +but changing bits from 0 to 1 individually or in any smaller granularity +(smaller than a sector) is impossible. + +What many "software-minded" programmers and tinkerers don't realize, however, +is that sector erasure is not an elementary or atomic operation that magically +"makes all bits 1s" in one motion. Instead it is a complex process with two or +three substeps: + +1) Before starting the physical process of erasure, one has to go through all + bits in the to-be-erased sector and make them all 0s. Any bits that are in + '1' state when the sector erase operation is commanded MUST be programmed to + '0' state before the actual erasure begins! In the language of flash chip + industry, this step is called preprogramming. In the case of flash chips + that are used in Calypso GSM devices (all known ones), this preprogramming + step is done internally by the chip, so that you as the user or software + developer are not aware of it - but it is there nonetheless. The chip does + NOT magically "wave" all bits in the sector into '1' state, instead it first + makes them all '0' internally, and only then erases. + +2) Once every bit in the sector is in '0' state, the real physics of erasure + begins. All bit cells in the sector are physically acted upon at once in + this step, and because it is a probabilistic process involving a Gaussian + distribution, all bit cells need to be in the fully programmed state before + they begin their shared journey toward the erased state. + +3) The step of preprogramming every bit to 0 prior to erasure prevents the + absolutely unacceptable condition of gross overerasure - but given the + Gaussian distribution, some bit cells may still get a little overerased. + Many (most? all? not sure) flash chips therefore implement a third internal + step before the software-visible "erase" operation is declared complete: + they go through all bit cells in the just-erased sector, check for + overerasure, and "soft-program" (move slightly to the right in the Vt + distribution) any overerased cells. This step is called post-erase + conditioning or recovery. + +The above process was originally explained to me (Mother Mychaela) some years +ago (around 2008, IIRC) by a Spansion support engineer on a conference call at +my then day job - it was a project for a customer who was big and powerful +enough to get top-tier support from chip vendors. More recently, however, some +other flash vendors have posted public documents that provide the same +explanation - here is one from Renesas/Adesto: + +https://www.freecalypso.org/pub/embedded/flash/REN_an500_APN_20210702_1.pdf + +Even though the above document was written by Renesas (or more precisely, the +part that was originally Adesto), the theory described therein applies just as +well to Intel, Spansion and Samsung flash chips that are used in Calypso GSM +devices. For anyone who wishes to know how NOR flash memory really works, I +strongly recommend reading that Renesas appnote - it is a good description. + +Additional note on terminology: describing the two states of a flash memory cell +as '0' and '1', like I did above, is only a convenience for software-minded +people. A more proper view is to think in terms of a "programmed state" and an +"erased state" for each bit cell. History and tradition are such that flash +chips return '0' on read in the programmed state and '1' in the erased state +(this tradition probably originates from the fact that the actual NV storage +element, a transistor, conducts read current in the erased state), at least for +the main flash array - however, when flash memory elements are used for +additional purposes such as write protection controls, it is best to think +natively in terms of programmed and erased states. For the latter kind of +special applications, an opposite polarity may be applied in read-bit values. + +One straightforward take-away from this theory is that flash endurance is really +about program-erase cycles, rather than number of program or number of erase +operations. Every time you give a sector erase command, every bit in that +sector cycles through the fully programmed (0) state first before becoming +erased (1), irrespective of whether or not you programmed into it on your own! +Hence every bit-cell of the affected sector always goes through a full +program-erase cycle, and all bits in a given sector are always cycled equally, +irrespective of whether they get written with mostly-0s or mostly-1s in between +erase cycles. + +Another situation where this raw physics gets exposed to the user is the case +of special-purpose non-volatile bits in flash chips outside of the main flash +memory array - for example, Persistent Protection Bits (PPBs) in some Spansion +and Samsung flash chips. While program and erase commands for the main flash +array invoke chip-internal mechanisms that take care of everything and present +a sane model of 0s and 1s to software, Spansion PL-J PPB program and erase +commands expose raw guts: there is a command that applies a raw program pulse +to a single PPB, and there is a command that applies a raw erase pulse to the +NV memory element (like a little sector of its own) that holds all PPBs. +Applying the erase pulse without preprogramming every PPB first would be very +bad (see Renesas appnote about the badness of overerasure) - hence in a seeming +paradox, one has to explicitly lock every sector before applying PPB erase +pulses that will eventually unlock everything! + +Our flash ppb-erase-all command does implement the preprogramming step before +actual erasure, and the present document (hopefully) explains why.