MicroSD Power-Loss Corruption: What Actually Protects Field Data

TL;DR

Power loss corrupts microSD data when the card is mid-write and either the card’s internal mapping, the filesystem metadata, or the host’s cached buffers are left inconsistent. No card on its own prevents this. What reduces risk is a combination of:

• Host discipline — flush and fsync at safe boundaries, and design the application so an unclean shutdown is recoverable.
• Power design — enough bulk capacitance and a supply that does not sag during write bursts; a clean brown-out detector that stops writes before the rail collapses.
• Card behaviour — the controller’s handling of an interrupted program/erase cycle and its internal mapping table, which varies by controller and firmware and is not captured by any speed class.
• Filesystem choice — append-only or log-structured formats tolerate interruption far better than in-place metadata updates.

The practical answer for B2B buyers is to treat power-loss robustness as a system property to be tested on your hardware, not a card specification to be bought. WINTEL supplies custom TF/microSD cards, USB drives, UDP modules and semi-finished boards to buyer specification; power-loss behaviour must be validated by the buyer against the target host, and WINTEL does not publish endurance, temperature or power-loss test results as a general claim.

What actually happens when power drops mid-write

A microSD card is not a disk with a head. It is a controller plus NAND flash, and the controller is doing several things at once: translating logical addresses to physical pages, managing wear, and writing to NAND in program/erase units that are larger than the logical sector. When power disappears during a write, several distinct failure modes can occur, and they are worth separating because they have different fixes.

1. The card was mid-program on a NAND page

NAND programming is not instantaneous. If the supply collapses while a page is being programmed, the page can be left in an indeterminate state. A well-designed controller detects the interruption on the next power-up and either completes or discards the operation using its internal mapping. A less robust implementation can leave the mapping table pointing at a page that no longer reads correctly. This is a card-side property and is not visible from the datasheet.

2. The filesystem metadata was half-updated

This is the failure mode most people actually see: the file is there but truncated, or the directory entry points at clusters that were reused, or the card mounts read-only. On FAT32 and exFAT, the file allocation table and directory entries are updated in place. An interruption between the two leaves an inconsistent view. Microsoft’s exFAT specification documents the structures involved; the practical consequence is that exFAT is not a transactional filesystem and does not promise consistency after an unclean shutdown (Microsoft Learn — exFAT specification, accessed 2026-10-22).

3. The host had data in its own cache

This is the failure mode most often missed. The operating system, the block layer, and the application may all hold data that has been “written” but not yet reached the card. If power drops, that data is simply gone, and the filesystem on the card may be perfectly consistent — it just does not contain the last N seconds of records. On Linux, the ext4 documentation describes the data=ordered default and the role of fsync in forcing data to stable storage (Linux kernel documentation — ext4, accessed 2026-10-22). On Apple platforms, the equivalent is an explicit synchronize call on the file handle (Apple Developer — FileHandle.synchronize(), accessed 2026-10-22).

4. The card’s internal cache was not flushed

Many cards buffer writes internally and acknowledge them before the NAND program has completed. The SD specification defines the states and commands the host uses to manage this, including the flush/cache operations in the physical layer specification (SD Association — SD Specifications, accessed 2026-10-22). If the host never issues the flush, or the card ignores it, acknowledged data can still be lost.

The chain of protection, and where each link fails

Link	What it protects	Where it fails	Who controls it
Bulk capacitance / supply	Prevents the rail from sagging during write bursts	Undersized caps, long thin cables, weak charger	Host hardware designer
Brown-out detection	Stops writes before the rail collapses	Threshold set too low, no interrupt to the app	Host firmware
Host flush / fsync	Forces cached data to the card	Called too rarely, or not at all	Host software
Card controller + firmware	Recovers an interrupted program/erase	Varies by controller; not specified by speed class	Card vendor / controller vendor
Filesystem	Keeps metadata consistent	In-place metadata updates (FAT/exFAT)	Host software / format choice
Application format	Keeps the record stream recoverable	In-place record updates, no checksums	Application developer

The important observation is that four of the six links are on the host side. Buying a “better card” addresses one link. It does not address the other five.

What speed classes do and do not tell you

The SD Association’s application performance classes (A1, A2) describe random read/write IOPS and sustained sequential performance for app-running use cases (SD Association — SD Standard Overview, accessed 2026-10-22). UHS speed classes (U1, U3) and video speed classes (V6 to V90) describe minimum sustained write throughput. None of these specifications describe power-fail behaviour. A card can be V90 and still lose a file on an unclean shutdown, because the class says nothing about how the controller handles an interrupted program.

This matters for procurement because it means you cannot specify power-loss robustness through a speed class. If a supplier offers you a card and cites U3 or V30 as evidence of data safety, that is a category error. The correct conversation is about controller family, firmware behaviour, and a validation test on your hardware.

The host-side fixes that actually move the needle

These are general engineering practices, not WINTEL data. They are the changes most likely to reduce field corruption in dashcams, loggers, and IoT devices.

Flush at safe boundaries, not continuously

Calling fsync after every record is expensive and accelerates wear. A better pattern is to buffer records in RAM, write them in aligned blocks, and flush at a boundary the application can recover from — for example, every N records or every T seconds, with a header that identifies the last complete block. On recovery, the application discards any trailing partial block.

Use a format that tolerates truncation

An append-only format with a per-record checksum and a length prefix is far more robust than in-place updates. If the last record is incomplete or fails its checksum, drop it and continue. This is the same principle behind log-structured filesystems, and it costs you a small amount of space and complexity in exchange for a much simpler recovery path.

Detect brown-out and stop writing early

A supply monitor that asserts an interrupt before the rail falls below the card’s minimum operating voltage gives the firmware time to finish the current block and flush. The threshold must be chosen with the bulk capacitance and the worst-case write latency in mind. This is a hardware and firmware design task; it cannot be retrofitted by changing cards.

Size the bulk capacitance for the worst-case write burst

Card write current is not constant. Bursts during program/erase can be significantly higher than idle current, and a supply that is adequate on average can still sag during a burst. The USB Power Delivery specifications describe the supply-side contract for bus-powered devices (USB-IF — USB documents, accessed 2026-10-22), but the local decoupling and bulk capacitance are the designer’s responsibility.

Mount read-only when the card reports errors

On Linux, the MMC/SD subsystem reports card errors up to the block layer, and the filesystem can be configured to remount read-only on error rather than continue writing to a failing card (Linux kernel documentation — MMC/SD subsystem, accessed 2026-10-22). Continuing to write to a card that is returning errors is how a recoverable problem becomes an unrecoverable one.

What the card side can and cannot promise

Card vendors can and do implement power-fail handling in the controller: detecting an interrupted program, maintaining a mapping table that can be rebuilt, and completing or discarding an in-flight operation on the next power-up. Some controllers do this well; some do not. The behaviour is not covered by the SD speed class specifications and is rarely documented in a datasheet.

What this means for a buyer:

• Ask the question directly. Ask the controller vendor or the card supplier how an interrupted program/erase is handled, and whether the mapping table is rebuildable. A supplier who cannot answer is telling you something.
• Test on your hardware, with your workload. A power-cut test rig that interrupts the supply at randomised points during a realistic write pattern, repeated enough times to be meaningful, is the only evidence that counts. This is a validation activity, not a purchasing decision.
• Do not accept a single pass as qualification. One successful recovery proves the card survived one interruption. It does not characterise the distribution of outcomes.

If you are evaluating sample cards before a production run, the sample acceptance checklist at /tools/sample-acceptance-checklist is a reasonable starting structure to extend with your own power-cut test cases. For background on how controllers handle bad blocks — which is related but not identical to power-fail handling — see bad block handling: what the controller does.

Where WINTEL fits, and what we do not claim

WINTEL (Shenzhen Wintel Digital Technology Limited) manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM/ODM buyers. Buyers specify capacity band, controller and firmware requirements, packaging and labelling; WINTEL builds to that specification.

What WINTEL does not do is publish a general power-loss protection claim, an endurance or TBW figure, a temperature range, or a test result as a marketing statement. Those are properties of a specific build against a specific host, and they belong in your validation plan, not in a datasheet headline. If a project needs a particular controller family or firmware behaviour, that is a specification conversation — start at /request-a-quote with the host platform, the write pattern and the failure modes you are trying to eliminate.

For related reading on how card selection interacts with workload, see how to choose a TF card for a dashcam and microSD A1/A2 application performance. If you are deciding between a removable card and embedded storage for a device that cannot tolerate an unclean shutdown, microSD card vs embedded eMMC covers the trade-offs.

A worked example of the arithmetic (Illustrative only — not WINTEL data)

Suppose a logger writes 4 KB records at 10 records per second, buffers 50 records in RAM, and flushes every 5 seconds. The worst-case data loss on an unclean shutdown is the unflushed buffer: 50 records, or 200 KB, or 5 seconds of data. If the application instead flushes every record, the worst case drops to one record — but the write amplification rises by a factor of 50, which matters for card wear.

The right point on that curve depends on how much data loss the application can tolerate and how long the card must last. There is no universal answer, and no card specification that resolves it for you. (Illustrative only — not WINTEL data.)

FAQ

Is a microSD card that survives power loss proof that my card is safe? No. A card that recovers once may have been mid-write in a region that happened to be intact. Corruption risk depends on where the write was when power dropped, how the card manages its internal mapping, and whether the host flushed its own buffers. A single successful test is not a reliability qualification.

Does a higher speed class protect against corruption? No. Speed classes (U1/U3/V30, A1/A2) describe throughput and random-IO behaviour, not power-fail robustness. A fast card with no data-integrity handling can lose a file just as easily as a slow one.

Can I prevent corruption entirely by choosing the right card? Not entirely. The card is one link in a chain that includes the power supply, the host’s filesystem and flush discipline, and the application’s write pattern. The most effective single change is usually on the host side — flush and fsync at safe boundaries, and design for a clean shutdown or a resilient log format.

Is a journaling filesystem on a microSD card a good idea? It helps metadata consistency, but journaling adds write amplification and can wear a card faster. For fixed-function devices, an append-only or log-structured format is often a better trade than a general-purpose journaling filesystem.

Can WINTEL guarantee power-loss protection on custom cards? No. WINTEL supplies custom TF/microSD cards, USB drives, UDP modules and semi-finished boards built to the buyer’s specification. Power-fail robustness depends on the controller, firmware, card design and host system, and must be validated by the buyer on the target hardware. WINTEL does not publish endurance, temperature or power-loss test results as a general claim.

Sources

• SD Association — SD Specifications, Part 1 Physical Layer: https://www.sdcard.org/downloads/pls/ (accessed 2026-10-22)
• SD Association — SD Standard Overview (speed classes, A1/A2): https://www.sdcard.org/developers/sd-standard-overview/ (accessed 2026-10-22)
• SD Association — Capacity: SDSC, SDHC, SDXC, SDUC: https://www.sdcard.org/developers/sd-standard-overview/capacity-sd-sdhc-sdxc-sduc/ (accessed 2026-10-22)
• USB Implementers Forum — USB documents (Power Delivery): https://www.usb.org/documents (accessed 2026-10-22)
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification (accessed 2026-10-22)
• Microsoft Learn — FAT32 file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/fat32-file-system-specification (accessed 2026-10-22)
• Linux kernel documentation — ext4: https://docs.kernel.org/admin-guide/ext4.html (accessed 2026-10-22)
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html (accessed 2026-10-22)
• Apple Developer — FileHandle.synchronize(): https://developer.apple.com/documentation/foundation/filehandle/synchronize() (accessed 2026-10-22)