NAND bad blocks and ECC: what flash buyers should verify

“This chip has bad blocks” sounds like an automatic rejection. In NAND flash, that conclusion is often wrong. Some blocks may be marked unusable at manufacture, more can wear out in service, and a correct storage design manages both without exposing them as user sectors.

The real red flags are different: using a marked block, applying insufficient ECC, exhausting the reserve pool, hiding uncorrectable errors or changing NAND without revalidating controller firmware.

A bad block is an erase block the system must not use

NAND is organized into pages for reading/programming and larger blocks for erasing. A bad block is a block judged unsuitable for reliable storage. There are two broad groups:

• initial bad blocks, identified during NAND manufacturing;
• grown bad blocks, retired after program, erase or read behavior fails in service.

KIOXIA explains that initial bad blocks are an inherent yield reality and may be included in shipped NAND. Raw devices mark them for the host; managed devices exclude them internally [2]. Micron specifies a minimum number of valid blocks at the end of the P/E-cycle rating and directs designers to follow the device's bad-block markers and error-management requirements [3].

Therefore, “zero factory bad blocks” is not a universal quality metric. The correct check is whether the device meets its valid-block specification and whether every marked block is excluded.

Raw NAND and managed flash assign responsibility differently

With raw NAND, the host processor and software stack must provide:

• initial bad-block scanning and a bad-block table;
• ECC at the strength and step size required by the data sheet;
• program/erase status checking and runtime block retirement;
• wear leveling, logical-to-physical mapping and power-fail recovery where needed.

Linux's raw NAND documentation exposes these responsibilities directly: bad-block marker positions, scan patterns, bad-block tables and ECC strength/step parameters are part of the integration [4].

With managed flash—such as eMMC, UFS, SSD and memory cards—the internal controller handles mapping, ECC and block retirement. When it detects a failed block, it marks it unusable and assigns a reserved replacement [2]. The host sees a logical address space rather than raw pages.

Managed does not mean immortal. It means the responsibility moved into the device, making controller and firmware part of the qualified storage component.

ECC corrects expected bit errors

NAND cells become harder to read perfectly as they wear, retain data for long periods and operate across temperature. Error correction code (ECC) adds redundant information so a supported number of erroneous bits can be detected and corrected.

KIOXIA describes the managed-flash sequence: on write, the controller calculates ECC and stores it with the data; on read, it checks and corrects bit errors before returning user data [1]. Raw NAND requires the host or controller outside the die to provide compatible ECC.

Three terms must remain separate:

A corrected error is not the same as a lost file. An uncorrectable error is actionable and must propagate to the host. Micron warns that ECC requirements differ by design and NAND type; the exact data sheet defines the required correction level [3].

Reserved blocks are a consumable reliability resource

Managed flash keeps spare blocks outside user-addressable capacity. The controller uses them when active blocks are retired. That maintains the advertised logical capacity—until the reserve pool approaches its limits.

KIOXIA documents pre-end-of-life indicators for eMMC and UFS based on reserved-block consumption, with warning/urgent or warning/critical states [2]. SSDs use their own SMART/NVMe fields, and removable cards may expose much less telemetry.

Deleting files does not replenish physical spare blocks. Free filesystem space can help garbage collection, but it is not the same thing as the controller's reserve pool. See NVMe SMART health fields for the SSD view.

Why a NAND or firmware change needs requalification

ECC requirement, page geometry, bad-block marker location, timing, read-retry behavior and wear characteristics vary across NAND generations. A controller/firmware combination validated for one die is not automatically safe with another.

For raw NAND, the host must match the exact data sheet. For managed products, the supplier must validate the controller firmware against the new NAND and preserve the promised external behavior and reliability. A capacity and speed spot-check will not reveal every mismatch.

That is why a fixed BOM and controlled-change process matter: NAND, controller and firmware identity belong in the qualification record.

A buyer's qualification checklist

For raw NAND or BGA designs, request and verify:

1. exact NAND part and revision;
2. required ECC strength and step size;
3. factory bad-block marker and scan procedure;
4. minimum valid-block specification;
5. program/erase failure handling and retirement rules;
6. read-retry and uncorrectable-error reporting;
7. power-fail behavior of the bad-block table and mapping metadata.

For managed flash, add:

1. controller and firmware revision;
2. accessible life and pre-EOL indicators;
3. policy when spare capacity approaches warning level;
4. full-capacity write/read verification across samples and lots;
5. endurance, retention, temperature and power-cycle tests matched to the application;
6. change-notification and requalification triggers.

Do not ask a supplier to promise “no bad blocks.” Ask for a system that never exposes marked blocks to user data, corrects within specification, reports when it cannot, and remains traceable when the BOM changes.

Bottom line

Bad blocks and ECC are normal parts of NAND engineering. Initial bad blocks can exist in a conforming raw device; grown bad blocks are retired as media ages; ECC corrects expected bit errors; reserved blocks preserve logical capacity. Reliability depends on correct implementation, sufficient margin, visible health signals and disciplined requalification—not a screenshot claiming every physical block is perfect.