Which microSD card should I specify for a medical wearable device?

TL;DR

Specify the smallest standard capacity band that covers your retention window, keep the card on FAT32 if you can, and treat the controller-plus-firmware combination as a BOM line item rather than a commodity. For most medical wearables — vitals loggers, event recorders, patch monitors, portable diagnostic accessories — that means an 8 GB to 32 GB card, FAT32 with a cluster size your firmware already handles, pre-formatted at the factory, and a written specification that names the controller family, the NAND generation and the exact format parameters.

Three things go wrong most often in this segment. First, buyers size the card to the largest number the marketing team likes rather than to the retention requirement, which pushes them into exFAT and a driver they have not tested. Second, the card is treated as fungible, so lot two arrives with a different controller and the field failure rate changes without anyone noticing. Third, power-loss behaviour is assumed rather than specified, and a device that loses battery mid-write comes back with a corrupt filesystem.

This guide walks through the checks a buyer in this segment should run before releasing a purchase order. It does not repeat the general engineering material covered elsewhere on this site — where a topic has a dedicated article, it is linked rather than restated.

Why this segment is different from consumer electronics

A medical wearable is usually a small, sealed, battery-powered device that writes a modest amount of data over a long period and is then read by a clinician, a companion app or a cloud service. The card is rarely user-accessible. That combination changes the priorities:

• The card is inside a sealed enclosure. You cannot ask the patient to reseat it. Whatever you ship is what runs for the life of the device, so the BOM lock-in matters more than the datasheet headline.
• Write rates are low but the device is always on. A continuous trickle of small writes is a different workload from a burst of video, and it stresses the filesystem and the controller’s wear handling rather than raw sequential throughput.
• Power loss is normal, not exceptional. Battery depletion, charger removal and firmware resets all cut power mid-operation. The card’s behaviour at that moment is a design parameter.
• The data may be evidence. Depending on the device class and the jurisdiction, the recording may need to be retained, reproducible and traceable to a specific build. That argues for lot traceability and a certificate of conformance rather than a spot check.

None of this makes the card exotic. It makes the specification discipline tighter than in consumer products.

Step 1 — Size to the retention window, not to the card

Start with the arithmetic, not with a capacity. Take the bytes your firmware writes per sample, multiply by the sample rate, add the per-write overhead your filesystem imposes, and multiply by the retention period you have promised. Then add headroom for firmware updates, log rotation and the fact that a full card behaves differently from an empty one.

For a device that writes a 512-byte record once per minute, the raw data is trivial — under 300 MB a year. Even with generous per-write overhead and a multi-year retention target, an 8 GB card is comfortable. For a device that records short audio or waveform bursts on demand, the number climbs quickly and 16 GB or 32 GB becomes the sensible band.

The practical point is that the capacity band you choose also chooses your file system, and the file system chooses how much driver work your firmware team has to do. Staying at or below 32 GB keeps you on FAT32, which almost every embedded FAT library handles. Crossing into 64 GB and above means exFAT, which is a different and larger implementation.

If you want the general reasoning on where capacity bands stop being economical, the article on capacity bands and where they stop making sense covers the crossover points. For this segment specifically, the crossover you care about is the FAT32-to-exFAT boundary at 32 GB.

There is a second sizing effect worth knowing about: usable capacity shifts with temperature, and in a wearable that sits against skin or inside a warm enclosure the card is not at room temperature. The mechanics are covered in capacity drift across temperature; the takeaway for procurement is to leave margin rather than sizing to 95% of the card.

Step 2 — Pick the file system your firmware can actually support

FAT32 and exFAT are the two realistic options for a removable card in a wearable. Each has a hard constraint that shows up in the field.

FAT32 caps a single file at 4 GB and, in the common implementations, caps the volume at 32 GB. For a logger that rotates files daily, the 4 GB file limit is irrelevant. For a device that records a single continuous session, it is a hard wall. Microsoft documents the limits in its maximum file size reference.

exFAT removes both limits and is the default on SDXC cards, but it requires a driver that implements the full on-disk structure described in the exFAT specification. On a small MCU with a third-party FAT library, that is real work, real flash and real test surface.

Constraint	FAT32	exFAT
Typical capacity band	up to 32 GB	64 GB and above
Max single file	4 GB	Practically limited by volume
Driver complexity on MCU	Low, widely available	Higher, needs a real implementation
Host PC compatibility	Universal	Universal on modern OSes
Suits	Log rotation, small records, event files	Long continuous recordings, large media

For most wearables, FAT32 at 8–32 GB is the lower-risk choice. If your retention requirement genuinely forces you above 32 GB, budget for the exFAT driver work as part of the project, not as an afterthought.

Whichever you choose, specify the cluster size. A 32 GB card formatted with 32 KB clusters and the same card formatted with 4 KB clusters behave differently under a stream of small writes, and the difference shows up as write amplification and, eventually, as filesystem errors. Lock the cluster size in the specification and have the factory format to it.

Step 3 — Understand what the host will and will not accept

The card is only half the interface. The other half is the host controller in your device, and its behaviour determines whether a given card works at all.

Most wearables use one of two interfaces: SD mode over a 4-bit bus, or SPI mode over a simpler pin count. SPI mode is easier to wire and easier to bring up on a small MCU, but it has a throughput ceiling and some cards behave differently under it. The trade-off is covered in SPI mode versus SD mode interface selection and the throughput ceiling specifically in SPI mode throughput.

The host also determines how errors are handled. A Linux-based host exposes card errors through the MMC subsystem, documented in the kernel MMC documentation; a bare-metal host has to implement its own retry and remount logic. Either way, the question to ask your firmware team is: what does the device do when a write fails? If the answer is “it retries forever” or “it panics”, the card specification will not save you.

Two host-side checks are worth running before you commit to a card:

1. Enumeration. Does the device reliably detect the card on cold boot, on warm reset, and after a brown-out? Some controllers are slower to initialise than the host’s timeout allows.
2. Filesystem mount. Does the device mount a freshly formatted card from a different tool than the one your factory uses? If not, your format parameters are not as portable as you think.

If the device is small enough that a removable card is questionable, the comparison in microSD versus embedded eMMC for portable devices is the relevant read before you commit to either.

Step 4 — Treat power-loss behaviour as a specification, not an assumption

A wearable loses power. The only question is what the filesystem looks like afterwards.

Two mechanisms matter. The first is whether the card’s controller finishes an in-flight write when power drops, or leaves a partially written block. The second is whether the filesystem’s metadata is updated in an order that survives an interruption. Neither is guaranteed by the card’s capacity or speed class.

The engineering options are covered in detail in microSD card power-fail-safe write strategy and in power loss, corruption and what protects data. For procurement, the practical actions are:

• Ask the firmware team to document the write pattern: append-only logs, atomic rename, or journal. Append-only with periodic fsync is the simplest pattern that survives interruption.
• Specify that the device reformats the card if it detects an inconsistent filesystem, rather than attempting repair in the field.
• Include a power-cut test in your acceptance criteria: cut power mid-write, restore, and verify the device recovers and the previously written records are intact.

That last item belongs in your sample acceptance process, which is covered in the sample acceptance checklist.

Step 5 — Decide whether endurance actually matters for your workload

Endurance marketing is loud and largely aimed at dashcams and security cameras, where the card is rewritten continuously. A medical wearable that writes a few megabytes a day is a different workload, and the endurance label tells you less than you might expect.

What does matter is consistency: the same controller and NAND generation across lots, so that the wear behaviour you validated is the wear behaviour you ship. That is a BOM question, not a datasheet question. The general mechanics of how controllers manage bad blocks are in bad block handling and what the controller does; the procurement consequence is that changing the controller changes the wear model.

If your device genuinely writes continuously — a continuous ECG recorder, for example — then endurance becomes a real specification and you should size the card so that the total bytes written over the device life stay well inside the card’s rated program/erase cycles, with margin for the write amplification your filesystem causes.

Step 6 — Lock the BOM before the first production run

This is where most of the risk in this segment actually lives. The card is small, cheap and easy to re-source, so it drifts. Six months later the field return rate has changed and no one can point to the change.

The items to lock, in writing, on the purchase order:

1. Controller family. Name it, not just “high quality controller”. A different controller means a different wear model and a different power-loss behaviour.
2. NAND generation and package. The die and package determine density, performance and the failure modes. The article on flash package formats explains why the package is a specification item.
3. Capacity band and usable capacity. Not just the printed capacity — the minimum usable capacity after formatting, measured on the factory’s own tooling.
4. File system, cluster size and format tool version. The exact parameters and the tool that produced them.
5. Pre-formatted or blank state. For a sealed device, pre-formatted is almost always right.
6. Label artwork and variable data. If the label carries a lot, a serial or a date code, the rules for that data belong in the specification. The article on variable data on each unit covers how that is handled.
7. Traceability. Lot code on the card or the packaging, and a record linking the lot to the production run. The reasoning is in flash memory lot traceability and die marking.
8. Certificate of conformance. What it actually attests to, and what it does not, is covered in certificate of conformance, what it says.

If your device is regulated as a medical device, the BOM lock-in also feeds your change-control process. A card change is a design change, and it should be treated as one.

Step 7 — Run the checks that catch the failures before they reach patients

Before releasing a production order, run a short, repeatable test on a sample from the actual production lot — not from a pre-production sample. The checks that catch the common failures in this segment:

1. Capacity verification. Confirm the usable capacity matches the specification, not just the printed label. The method is described in fake USB drive capacity and how to check, and the same principle applies to cards.
2. Format and mount on the device. Insert a factory-formatted card into a production-representative device and confirm it mounts and writes on first boot.
3. Power-cut recovery. Cut power mid-write, restore, and confirm the device recovers and previously written records are intact.
4. Temperature soak. Run the device at the extremes of its operating range and confirm the card still enumerates and the filesystem still mounts. The temperature effect on usable capacity is covered in capacity drift across temperature.
5. Lot comparison. Compare a sample from the new lot against a retained sample from the previous lot on the same tests. Any difference is a change-control event.

For buyers who want a structured acceptance process rather than an ad-hoc test, the sample acceptance checklist is the starting point.

Step 8 — Write the purchase order so it can be enforced

A purchase order for cards in this segment should carry more than a part number and a quantity. The items below are the ones that show up in disputes.

1. Specification reference. A revision-controlled document that names the controller family, NAND generation, capacity band, file system, cluster size and format tool version. The PO references the document, not a verbal description.
2. Acceptance criteria. The tests from Step 7, written as pass/fail, with the sample size and the lot from which the sample is drawn.
3. Traceability requirement. Lot code on the unit or the packaging, and a record linking the lot to the production run.
4. Certificate of conformance. What it attests to, and the process for a non-conformance.
5. Change notification. A written commitment that any change to controller, NAND or format parameters is notified before shipment, with a sample for re-qualification.
6. Packaging and labelling. How the cards are packed, how they are labelled, and how the label data is generated.
7. Delivery and quantity tolerance. The acceptable over/under on quantity, and the delivery window.
8. Retention sample. A retained sample from each lot, held for a defined period, so that a field issue can be compared against the shipped build.

If the order is the first one, the article on how long a custom microSD order takes covers the timeline, and how long a pre-production run takes and why explains why the sample stage is not compressible.

What WINTEL can and cannot confirm for this segment

WINTEL manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM/ODM buyers. The company operates a 5,000 m² facility in Shenzhen with a stated capacity of 500,000+ units per month and holds SGS, RoHS, CE and FCC certifications.

What that means for a medical wearable buyer is that WINTEL can quote to a written specification, format cards to specified parameters, apply label artwork and variable data, and supply lot traceability. It does not mean WINTEL has published endurance ratings, temperature ranges, speed classes or medical-device certifications for a specific card — those are product-specific and must be confirmed against the actual specification for your part number, not assumed from this article.

If your device is a regulated medical device, the qualification work — including any testing your regulatory pathway requires — sits with you as the device manufacturer, and the card specification is one input to it.

FAQ

What capacity should a medical wearable card be? Size to the retention window, not to the card. Take daily bytes written × days of retention × a headroom factor, then pick the smallest standard band that clears it. For most vitals loggers and event recorders that lands in 8–32 GB, which keeps you on FAT32 and away from exFAT driver work.

Is a high-endurance or “industrial” card required? Only if your host writes continuously. A device that logs a few MB per day does not stress the card the way a dashcam does. What matters more is predictable power-loss behaviour and a locked controller/firmware combination, not a marketing endurance label.

Can the device format the card itself? Yes, and it should. Ship cards pre-formatted to the exact cluster size your firmware expects, and have the device re-format on first boot or on a detected filesystem mismatch. Do not rely on the user formatting on a PC.

Do I need a card with a specific speed class? Speed class guarantees sustained sequential write, which matters for video. For low-rate sensor logging, random-write behaviour and controller consistency matter more. Specify the class your firmware actually needs and test it; do not pay for a class you cannot use.

What should be locked in the BOM? Controller family, NAND generation, card capacity band, file system and cluster size, formatted/unformatted state, label artwork, and the firmware version used for the production format. Anything not written down will drift between lots.

Sources

• SD Association — SD Specifications, Part 1 Physical Layer and Part 2 File System: https://www.sdcard.org/downloads/pls/ (accessed 2026-10-31)
• SD Association — Capacity and file system guidance for SDHC/SDXC: https://www.sdcard.org/developers/sd-standard-overview/capacity-sd-sdhc-sdxc-cards/ (accessed 2026-10-31)
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification (accessed 2026-10-31)
• Microsoft Learn — Maximum file size (FAT32 limits): https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-size (accessed 2026-10-31)
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html (accessed 2026-10-31)
• JEDEC — Standards and documents (managed NAND / eMMC): https://www.jedec.org/standards-documents (accessed 2026-10-31)