Reliable NAND Flash Storage for Indian Industrial…

Walk into any Indian industrial equipment design house, the factories in Pune that build motor drives, the railway signalling vendors in Bengaluru, the metering firms in Hyderabad, the process control teams in Chennai, and you will see the same storage problem on every bench. The product has a 10-year, sometimes 30-year field life. It sits in a switchgear cabinet or a trackside relay room, writing event logs, fault records, parameter sets, and calibration data into flash. The product costs a few thousand rupees in BOM, and the customer expects it to outlive the engineer who built it. And the storage element is raw NAND flash, not managed NAND, not eMMC, not an SSD, just a plain serial or parallel NAND chip on the board.

Raw NAND is cheap, it is available on shelves across India, and it is still the default for long-life industrial and railway designs. But raw NAND is also where firmware projects go to die, because raw NAND requires you to implement wear-levelling, ECC, bad-block management, and power-fail-safe journaling correctly. Get any of those wrong and the product corrupts itself in the field, usually years after the engineer who shipped it has moved on.

SEGGER emFile is the filesystem that most serious Indian industrial teams reach for when they need to do raw NAND correctly. GSAS Micro Systems is India’s authorized engineering partner for SEGGER Microcontroller GmbH, and we license emFile into customer projects across Bengaluru, Chennai, Hyderabad, Pune, Mumbai, and Delhi NCR. This post explains the emFile NAND architecture, the ECC and wear-levelling choices, and a concrete railway data-logger scenario that maps cleanly onto how Indian teams are actually using this middleware today.

Why raw NAND still matters in Indian industrial design

Before the middleware question: why does raw NAND survive in 2026, when managed NAND and eMMC are on every shelf? Three reasons that Indian industrial teams cite repeatedly.

First, cost. A small-density SLC NAND costs a fraction of the equivalent eMMC. When your BOM target is aggressive and you only need a few megabytes of storage, raw NAND is the cheapest option per bit.

Second, inventory. Raw SLC NAND has been in continuous production for two decades. Indian distributors carry inventory of well-known parts from Winbond, Micron, Macronix, Toshiba, ISSI, and Alliance Memory. For railway and industrial programs that need a 10-15 year supply guarantee, a widely-stocked raw NAND part is far easier to second-source than a specific eMMC SKU.

Third, control. Managed NAND hides the FTL from you. For a product that needs to be auditable, and railway signalling equipment under RDSO (Research Designs and Standards Organisation) qualification absolutely does, seeing exactly how data is laid out, exactly when a block is erased, and exactly how bad blocks are retired, matters more than the convenience of a black-box eMMC controller.

The consequence is that raw NAND stays on Indian industrial bills of materials. Which means the firmware team has to handle NAND correctly. Which means they need a filesystem that was designed for raw NAND from day one.

The emFile NAND driver architecture

emFile’s NAND stack is layered, and every layer maps to a specific NAND failure mode. From the top down:

Filesystem layer: FAT (for interoperability with Windows and Linux hosts) or the optional EFS (SEGGER’s journaling filesystem with power-fail safety as a first-class feature). For industrial loggers the EFS option is the usual choice.

FTL (Flash Translation Layer): maps logical sectors to physical NAND pages. This is the layer that hides the “erase before program, program in pages, erase in blocks” nature of NAND from the filesystem above.

Wear-levelling layer: keeps erase counts balanced across the device so that no single block wears out while others sit unused. emFile supports both dynamic wear-levelling (moves hot data off frequently-rewritten blocks) and static wear-levelling (occasionally migrates cold data to give old blocks a rest).

ECC layer: computes and checks error correction codes on every page. emFile supports BCH ECC at 4-bit, 8-bit, and 24-bit strengths, chosen to match the NAND vendor’s endurance specification.

Bad-block management layer: tracks factory-marked bad blocks at device initialisation, discovers runtime-bad blocks when ECC correction fails or program/erase returns a failure status, and retires them into a reserved block pool so that the filesystem above never sees a bad block.

NAND hardware driver: the thin layer that actually drives the SPI-NAND or parallel NAND interface on your MCU. emFile ships with drivers for the common STM32 FMC/FSMC, NXP iMX-RT FlexSPI, and generic SPI-NAND paths.

The important property of this stack is that each layer is documented in the emFile User Manual UM02001, which SEGGER publishes openly. Your RDSO or IEC 61508 auditor can ask for the filesystem architecture document, and you can provide a current, vendor-maintained reference, which is very different from an in-house FTL that one engineer wrote in 2019 and nobody else fully understands.

Picking the right ECC scheme: 4-bit, 8-bit, 24-bit BCH

NAND vendors specify a minimum required ECC strength per page. On older SLC parts, 1-bit or 4-bit ECC was enough. On modern SLC, 4-bit is the common minimum. On MLC and TLC parts, the minimum jumps to 8-bit or 24-bit BCH. If you use less ECC than the vendor specifies, you will see silent data corruption near the end of the part’s endurance rating, not at day one, but at year three or year five, which is exactly the wrong failure mode for a railway logger.

emFile lets you select the ECC strength at driver configuration time. The rule is simple: read the NAND datasheet, find the “minimum required ECC” line, and configure emFile at least that strong. For safety margin on a long-life industrial product, it is common to go one step stronger, 8-bit on a part that requires 4-bit, 24-bit on a part that requires 8-bit. The cost is a slightly larger out-of-band area usage and marginally more CPU to compute the code; the benefit is that the storage keeps working through the entire specified lifetime.

Wear-levelling tuning for write-heavy vs read-mostly workloads

Not all industrial storage looks the same. A metering endpoint logging half-hourly energy snapshots writes a handful of kilobytes per day. A vibration data logger on a motor drive writes hundreds of kilobytes per second during a fault capture event.

emFile’s wear-levelling algorithm is tunable. For write-heavy loads, dynamic wear-levelling is the workhorse, every new write is steered to the least-worn available block, so erase counts stay flat across the device. For read-mostly workloads (calibration data, configuration, device identity) static wear-levelling matters more, because without it the cold data would sit forever on a small subset of blocks while the rest of the device cycles around it and eventually asymmetric wear emerges. emFile combines both, and lets you configure the frequency at which static wear-levelling sweeps kick in.

A good rule for Indian industrial teams: if your write pattern is bimodal, a small amount of hot configuration and a large stream of cold event logs, let the defaults run, measure erase count distribution after a few days of realistic load, and only tune if the distribution is skewed.

Bad-block management and the reserve pool

Every NAND part arrives from the factory with some blocks marked bad. Over its lifetime, additional blocks will be discovered bad as ECC correction fails or program/erase operations return failure. emFile maintains a Bad Block Table (BBT) on the device that tracks both categories, and retires bad blocks into a reserve pool.

The reserve pool is sized at filesystem format time. The rule of thumb is to reserve enough blocks that the expected lifetime bad-block growth fits comfortably. For an SLC NAND with 100k erase cycles per block, a reserve pool of 2-5% of total blocks is usually sufficient for a 10-year deployment. For MLC parts with lower endurance, 5-10% is safer. emFile documents the sizing calculation in UM02001.

A concrete scenario: an STM32H7 railway signalling logger

Picture an Indian railway signalling data logger on an STM32H7 Cortex-M7 with a Winbond SLC NAND part on the FMC bus. The product sits trackside in a relay cabinet, logs signalling events and fault traces, and has a 10-year data retention requirement under an RDSO qualification profile.

The emFile configuration for this kind of design typically looks like:

EFS filesystem layer (journaling, power-fail safe)
8-bit BCH ECC on the NAND driver (one step stronger than the part’s 4-bit minimum)
Dynamic + static wear-levelling, defaults
3% reserve block pool at format
Wrapper APIs that the application uses to atomically commit a “transaction”, an event log entry or a fault trace file, so that a power loss mid-write always rolls back cleanly to the previous committed state

The test plan for this kind of device usually includes a brutal power-cycle test: a rig that power-fails the logger at random intervals during active writes, thousands of times, and verifies that the filesystem is always mountable and always consistent. emFile’s journaling design makes this test pass; it is very difficult to make a home-grown FTL pass it.

Power-fail safety and the realities of an Indian industrial site

A factory floor in Pune, a process plant in Visakhapatnam, a remote railway signalling location in Andhra Pradesh, these are not clean-power environments. Voltage dips, phase imbalance, operator-triggered contactor openings, and simple cable faults all end up as a DC rail that drops to zero without warning the firmware.

emFile’s EFS layer is designed for exactly this. Every write is journaled. If power drops mid-write, the next boot replays or rolls back the journal and the filesystem is consistent. This is not unique to emFile, any serious journaling filesystem does it, but it is unique in that emFile journals across raw NAND, through the FTL, with bad-block tolerance, which is not something a generic journaling filesystem designed for block devices can do without a lot of custom glue.

Alternatives, honestly compared

The three options Indian teams commonly consider:

FatFs + a custom NAND driver. FatFs is free and well-known. It was designed for block devices (SD cards, eMMC), not raw NAND. To use it on raw NAND you have to write your own FTL and wear-levelling under it, and the resulting stack is fragile unless you invest significant engineering into it. For a product with a 10-year field life, “fragile” is not acceptable.

Vendor FTLs. Some NAND vendors offer reference FTLs bundled with their parts. They work, but they lock the design to that vendor’s part, which defeats the second-sourcing argument that made you pick raw NAND in the first place.

SEGGER emFile. Portable across NAND vendors, maintained by SEGGER, documented in UM02001, supported commercially, tested on millions of deployed units. Royalty-free per product once licensed. This is the choice that most Indian industrial teams converge on once they have been burned by one of the first two options.

Debugging filesystem issues with J-Link and RTT

One of the quiet advantages of picking emFile is that it is designed by the same team that makes J-Link and SystemView. When you need to debug a filesystem issue, a wear-levelling hot spot, a bad-block miscount, a journal replay that did not recover cleanly, you get an end-to-end toolchain that already speaks to itself. RTT (Real-Time Transfer) carries filesystem trace logs off the target at full SWD speed without perturbing the write path, and SystemView shows filesystem activity in the same timeline as your RTOS tasks and ISRs, so you can see which task was writing when the fault happened.

Licensing emFile through GSAS

emFile is commercial middleware with a royalty-free per-product licensing model. GSAS Micro Systems, as India’s authorized SEGGER partner, handles the full licensing workflow: design-in evaluation, source code license, royalty-free product license, renewal support, and local application engineering from our offices in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR. For teams new to emFile, we can also arrange a short evaluation window so your engineers can prove out the NAND driver on their actual hardware before procurement.