Author: MaxW_71 Version: **
Translation - Japanese: FS512Sのブランクチェックと条件付き消去がデフォルトでOFFになっている理由 - KBA228049 - Community Translated (JA)
The answer is a little long, so bear with us:
The Evaluate Erase Status (EES) feature, which was first introduced for the FS-S family and has been included on every MirrorBit® design since. Internally, the design uses the “erase power loss indicator” (EPLI) method that we use to track whether the erase completed successfully. It is the EPLI feature that gives the blank check feature its value.
The EPLI feature is built into the erase command and is almost hidden from the user interface (UI). When the erase command starts, we leave a non-volatile “breadcrumb” to record the start of the erase. While the erase algorithm progresses under continuous power, the flash’s internal MCU monitors the progress; if it observes “erase complete” at the end of the process, the algorithm leaves a second non-volatile “breadcrumb” to record the correct completion of the erase algorithm. This allows us to create the UI feature called “Evaluate Erase Status”. If the EES command sees the first breadcrumb, and not the second, the prior erase on that sector did not complete under continuous power. Once the system sees that a sector was subjected to an interrupted erase, the system can initiate another erase command to render the sector trustworthy for further reading and programming.
The reason this background is important can be seen from the blank check feature on an earlier device, which did not have the EPLI logic. In this case, a “blank” result on any given sector is of marginal value, because neither the flash nor the system knows if the “all 0xFF” pattern is based on a trustworthy erased state, or an untrustworthy (partially) erased state. In other words, a test result showing “all 0xFF” is not a sufficient condition for proving that the sector is blank, properly erased, and trustworthy for programming and reading. In contrast, on the FS512S with the blank check feature turned on, the erase is skipped if and only if the EPLI check shows “prior erase completed” and the blank check shows “all 0xFF”. For the system, this means that when the erase command skips the erase process, saving milliseconds to seconds of busy time; and most importantly, the system architect can believe the sector is trustworthy for programming and reading.
The automatic blank check is turned off by default because it adds milliseconds to every erase, whether it’s blank or not.
Thus, the automatic blank check feature has some tradeoffs that may or may not benefit your application. The biggest benefit is expected for the “read-only” use case where a subset of the sectors to be erased are already blank and ready for programming and reading.