Firmware as a storage risk: update paths that break cards

TL;DR

Firmware is the layer that decides whether a flash device actually keeps your data. The NAND die only stores charges; the controller firmware does the wear levelling, the bad-block management and the mapping the host reads. A good implementation makes modest NAND last, while a weak one loses data on good silicon. The risks buyers miss are concrete: a botched or interrupted firmware update can scramble the mapping and brick the part, some firmware over-reports capacity or leans on a cache it cannot sustain, and a device that enumerates cleanly on one USB host can fail on another. The endurance figures themselves, SLC about 100,000 program-erase cycles, TLC about 1,000 to 3,000 and QLC about 300 to 1,000, are JEDEC published cell-type averages, not measurements from any one factory floor, and firmware is the multiplier on all of them.

The layer nobody shops for

Buyers compare capacity and read speed. Those numbers sit on the box. The part that actually determines whether the files are still there in eighteen months is the controller firmware, and it is never on the box.

A NAND die is passive. It stores a charge in a floating gate and reports back whatever the controller asks it to report. The controller is the active intelligence: it decides which physical page holds your logical block, it spreads writes so no block wears out first, it retires blocks that go bad, and it presents a clean capacity number to the host. Every one of those jobs is software running on a small chip. That software is the firmware.

This is why two cards built on the same NAND can behave completely differently. The silicon is similar; the firmware is not. When a procurement spec lists only capacity and interface, it leaves the single most failure-prone component unspecified.

What firmware does on the chip

The flash translation layer (FTL) is the core. Logical block zero is almost never physical block zero. The FTL maps the host’s view onto the NAND’s physical pages, and it rewrites that map on every write because NAND cannot overwrite in place, it must erase a whole block before it can reuse it.

Wear levelling sits on top of the FTL. Without it, a log file or a filesystem journal would hammer the same blocks until they fail early, while the rest of the chip stayed fresh. Bad-block management watches for cells that stop holding charge and routes around them. Error correction rebuilds data from parity when a read comes back noisy.

None of this is visible to the buyer. A controller that does it well makes a modest TLC part behave like a reliable drive. A controller that cuts corners, to save cost or to inflate a benchmark, can lose data on NAND that was perfectly good.

The JEDEC numbers, and why firmware is the multiplier

The endurance figures people quote come from published cell-type averages, not from any single factory’s floor. JEDEC, in JESD47 and JESD84, sets them out: SLC about 100,000 program-erase cycles, MLC about 3,000 to 10,000, TLC about 1,000 to 3,000 and QLC about 300 to 1,000.

Total bytes written is estimated as capacity times P/E cycles divided by a write amplification factor, and that factor commonly runs 8 to 20x on managed NAND because data is programmed in pages and erased in blocks. Retention follows a similar published curve: about 10 years at 40 C at the start of life, dropping to about 1 year at 40 C after 3,000 P/E cycles.

These are published industry averages from JEDEC, not measurements taken on our own line, and the exact limits are subject to the latest official wording. The reason they matter here is that firmware is what realizes them. A good FTL keeps write amplification near the low end of that 8 to 20x band; a poor one pushes it up and quietly burns through the P/E budget early. The NAND rating is a ceiling. Firmware decides how close to it you get.

Update paths that brick a device

A finished drive rarely ships with a documented update path, and that is itself a risk worth naming. When a device is field-updatable, the update is the most dangerous five minutes in its life.

An interrupted update, a partial flash, or a build with a mapping bug can leave the translation layer inconsistent. After that, the host may read garbage, report the wrong capacity, or fail to enumerate at all. The card is not physically damaged; its brain is confused. Recovery without a documented fallback is often impossible, and the data on it is gone with it.

The safe pattern is boring: the update is atomic, power loss mid-update leaves the previous firmware intact, and there is a recovery path the supplier will describe in writing. If a vendor cannot tell you what happens when power drops during an update, that is the answer.

Capacity reporting, and the SD classes

Firmware also decides what capacity the host believes the device has. The SD Association defines capacity classes for a reason: SD up to 2 GB, SDHC 2 to 32 GB, SDXC 32 GB to 2 TB, SDUC 2 to 12 TB. A controller that reports a class it cannot back with real, verified space is the oldest scam in the category, and it survives because the host trusts the number the firmware hands it.

The only test that does not take the device at its word is write-and-read-back: fill the whole nominal capacity, then read every byte back and compare. A fake reports data lost, corrupted or overwritten past its real limit. That test is independent of whatever the firmware claims, which is exactly why it is the one buyers should run on a sample.

These capacity classes are the SD Association’s published specification, not a WINTEL measurement, and the boundaries are subject to the latest official wording. Cite the body, not a single supplier, when you write the requirement into a spec.

USB enumeration is a firmware promise

A removable drive is a USB device, and how it presents itself to the host is a firmware behaviour defined against the USB Implementers Forum’s classes. The USB-IF publishes the signalling ladder: USB 2.0 High-Speed at 480 Mbit/s raw, USB 3.2 Gen 1 at 5 Gbit/s, Gen 2 at 10 Gbit/s and Gen 2x2 at 20 Gbit/s, with the marketing names themselves renamed along the way, USB 3.0 becoming USB 3.2 Gen 1 and USB 3.1 becoming USB 3.2 Gen 2.

Those are USB-IF figures, not a WINTEL test result, and the exact rates are subject to the latest official wording. The point for firmware risk is narrower: a device that enumerates cleanly on one host’s USB stack can fail on another, because the handshake is a promise the firmware makes and not every controller keeps it equally well. A card that passes on the bench PC can drop on an embedded reader, an old hub, or a car head unit, and the cause is frequently the firmware’s handling of the enumeration, not the NAND.

Our own modules

We build removable flash, UDP (USB Disk in Package) modules and TF cards and semi-finished boards, and the dimensions we publish are taken from the parts we ship, not an industry average. Our UDP modules measure 11.3 × 24.8 × 1.45 mm at 0.819 g and run from 128MB to 128GB. Our TF cards measure 15 × 11 × 1 mm at 0.25 g, from 4GB to 256GB. Our semi-finished boards measure 12 × 44 × 4.5 mm at 3.2 g, also 128MB to 128GB.

Those numbers are our own product specifications. The endurance and interface figures in the sections above are not; they are JEDEC and USB-IF published standards. We keep the two separate on purpose, because a buyer who confuses a published average with a supplier’s measured result is exactly the buyer who gets burned.

What to put in the purchase order

Treat firmware as a qualified component, not a free variable.

Name the controller solution so a reorder cannot silently swap it. State whether the firmware is fixed or field-updatable, and if it is updatable, require a documented recovery path and an atomic update guarantee. Ask for the wear-levelling and bad-block policy in writing. Require that the reported capacity survive a write-and-read-back test across the full nominal size, not just a quick format check. Lock the firmware revision in the order so a future batch behaves like the one you qualified.

A supplier who treats these as odd questions is telling you they have not thought about the failure mode that ends with your customer’s data missing.

When you should not buy a drive from us

Be wary of any finished module, ours included, when the job is boot-critical and you cannot tolerate firmware you did not write or audit. A sealed consumer-grade part whose translation layer you cannot inspect is the wrong answer for life-safety systems, long-unattended telemetry, or legally-recorded data where silent loss is unacceptable. In those cases a managed part with your own FTL, or a supplier who puts the firmware policy in the contract, is the safer build.

Also walk away from a quote that competes purely on price per gigabyte with no controller named. The firmware risk is exactly where the cheapest parts fail, months after the warranty argument has gone cold. And if you need a device you can field-update but the vendor cannot describe the recovery path, do not ship it, because the update that bricks it is a matter of when, not if.

What we ask before we quote

Five facts sort almost every enquiry. Which host the device plugs into, and whether enumeration has ever failed there. Whether the firmware may be field-updated or must be fixed. What the data is worth if it goes missing. The capacity and environment the part must survive. And whether you need the controller revision locked across reorders.

With those five answers we can usually say in one reply whether a UDP module, a TF card or a semi-finished board is the right build, and where the firmware terms need to be written down before a single unit is made.