Changes

__FORCETOC__

{| class="wikitable" border="1"

!Version

|First public release

|}

In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, [https://www.micron.com/products/nand-flash/choosing-the-right-nand raw NAND flashes], eMMC's, etc.).

This Technical Note deals with the use of read/write file systems in combination with such memories providing some real-world examples as well.

Some of the following examples refer to embedded Linux systems making use of NOR flashes or raw NAND flashes. Such systems are commonly managed by [http://www.linux-mtd.infradead.org/doc/general.html MTD]/[http://www.linux-mtd.infradead.org/doc/ubi.html UBI] subsystems and, on top of them, [http://www.linux-mtd.infradead.org/doc/ubifs.html UBIFS] to manage files.

Therefore, before diving into these examples, we suggest to take a look at our [[Memory Tecnology Device (MTD)]] article where these subsystems are explained in more detail.

One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.

where D is the amount of data written in the unit of time of interests (month, year, etc.).

This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.

LT = 20000 / 650 = 30.8 years

In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.

</syntaxhighlight>

Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].

(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.

Even though both UBI and UBIFS [http://www.linux-mtd.infradead.org/doc/ubi.html#L_powercut are designed with power-cut tolerance in mind] without having support from additional hardware (e.g. supercap, battery power supply, and so on) some data might be lost and some ''weird'' effect happens when not performing a clean shutdown of the system.

* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer UBIFS write-buffer].

TBD

Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.

There's two main indicator of NAND device health:

* current ECC corrected errors

</syntaxhighlight>

TBD