microSD Cards for Industrial Control Panels and HMIs — What to Buy

TL;DR

For industrial control panels and HMIs, buy a small card on purpose: 8 GB to 32 GB, FAT32, industrial-grade NAND, and a locked BOM entry that specifies the controller and firmware behaviour — not just the retail model name. Most panels store recipes, alarm logs, trend history and firmware images, not video. A 32 GB card is usually generous; a 128 GB card is usually a liability because it pushes the host into SDXC and exFAT territory that older firmware may not mount.

Three rules cover most of the decision:

1. Size to the log volume, not to the price ladder. Measure what the panel writes per day and multiply by your field-service interval.
2. Stay in SDHC (≤32 GB) unless the host firmware documents SDXC support. This is the single most common integration failure.
3. Buy for power-fail behaviour and endurance, not for the U/V/A speed badge. A panel is not a camera.

The rest of this guide walks through the checks a buyer or hardware engineer should complete before releasing a purchase order, and ends with a purchase-order checklist written as numbered prose you can act on rather than a form to fill in.

Why industrial panels are a different buying problem

An HMI or PLC-adjacent panel uses its card in a way that looks nothing like a phone or a dashcam. It writes small records — a few hundred bytes of alarm text, a recipe table, a trend sample — at low but steady rates, and it does so for years. It also loses power without warning, because the machine it controls is switched off at the end of a shift, or because a fault trips the line.

That combination — small steady writes plus abrupt power loss — is what kills cards in the field. It is not a bandwidth problem. A card that writes 100 MB/s can still corrupt its file allocation table on the third unannounced power cut if the controller does not handle flush correctly.

There is a second structural difference. Industrial panels are long-lived products. A panel designed in 2026 may still be in service in 2036, and the card you qualified in 2026 may have had its internals revised twice by then. Procurement therefore has to lock more than a part number; it has to lock a specification and a change-notification process.

If you want the underlying mechanics of power loss and what protects data, the technical article on microSD card power loss, corruption and what protects data covers it in depth. This guide stays at the buying level.

Check 1 — Size the capacity band from the log volume

Start by asking the firmware team one question: how many bytes does the panel write per day at the 95th percentile? Then multiply by the field-service interval and add a margin for firmware images and recipe backups.

A worked example, purely to show the arithmetic:

• Alarm and event log: 2 MB per day
• Trend history: 8 MB per day
• Recipe and configuration snapshots: 5 MB per week
• Firmware image staged for update: 60 MB

Over a 90-day service interval that is roughly 0.9 GB of logs plus about 65 MB of snapshots and firmware — under 1 GB. A 8 GB card leaves an order of magnitude of headroom. (Illustrative only — not WINTEL data.)

This is why 8 GB to 32 GB is the practical band for panels. If your numbers land in the same range, you are buying for reliability and longevity, not for capacity. The general logic of where capacity bands stop being useful is covered in capacity bands — where they stop making sense, and the WINTEL TF card capacity estimator can help you sanity-check the arithmetic.

Two caveats:

• Wear-levelling headroom. A card that is 90% full has far less free space for the controller to spread writes across. Leave at least half the card empty at end of life. This argues for buying slightly larger than the raw log math suggests, not smaller.
• Capacity drift across temperature. Some hosts report a slightly different usable capacity at temperature extremes, and some firmware reacts badly to a card that reports a smaller size than expected. The article on capacity drift across temperature explains what to test.

Check 2 — Choose the file system your host actually mounts

The file system decision is where most integration projects go wrong, and it is decided by the host firmware, not by the card.

FAT32 is the default answer for industrial panels. It is the most widely supported file system in embedded firmware, it is what most vendor update procedures expect, and it works on SDHC cards up to 32 GB out of the box. Its limits are well documented: Microsoft specifies a 32 GB maximum volume size for FAT32 formatting on Windows and a 4 GB maximum file size (Microsoft Learn — maximum file size). Neither limit matters for a panel writing 2 MB logs.

exFAT removes both limits and is the default file system on SDXC cards above 32 GB (SD Association; Microsoft Learn — exFAT overview). It is a good choice if your host firmware ships an exFAT driver and you have validated it. It is a bad choice if you are assuming the driver is there.

The decision table:

Host firmware situation	Recommended file system	Capacity band
Older or stripped-down RTOS, no exFAT driver	FAT32	8–32 GB (SDHC)
Embedded Linux with exFAT enabled in kernel config	FAT32 or exFAT	8–32 GB, or 64 GB+ if measured
Vendor update procedure specifies a format	Follow the vendor exactly	As specified
Host only mounts FAT32 and rejects exFAT silently	FAT32	≤32 GB

The silent-rejection case is the dangerous one. Some hosts will mount an exFAT card, report success, and then fail to write. Always confirm the file system by reading back a file the panel wrote, not by trusting a mount message.

The Linux kernel documentation for the MMC subsystem (docs.kernel.org) is the reference for how the host controller handles card detection, write caching and flush, and it is worth reading before you assume a given board supports a given card class.

Check 3 — Confirm what the host controller will and will not accept

The card is only half the interface. The other half is the host controller in the panel, and its limits are set by the board design and the kernel or RTOS driver. Before you commit to a card, confirm:

1. Maximum supported capacity. Some controllers address only SDHC (≤32 GB). Some address SDXC. The board schematic and the SoC datasheet will tell you; the retail card packaging will not.
2. Supported bus mode. SPI mode, 4-bit SD mode and high-speed modes are not interchangeable in practice. The article on microSD card SPI mode throughput ceiling covers why an SPI-only host caps throughput regardless of the card’s rating.
3. Card-detect and hot-plug behaviour. If the panel does not support hot-plug, the card is effectively soldered in place and the buyer should treat it as a fixed component with a service life, not a user-swappable accessory.
4. Power sequencing. Does the host cut card power before or after the SoC? A host that removes card power while a write is in flight is the classic corruption scenario.
5. Write-cache and flush. Does the driver issue flush commands, or does it rely on the card’s internal handling? The article on microSD card power-fail safe write strategy explains the difference.

If the answer to any of these is “we don’t know”, the correct next step is a bench test, not a purchase order. The sample acceptance checklist is a useful starting point for what to test on a single card.

Check 4 — Buy for endurance and power-fail behaviour, not for speed class

Speed classes (U1/U3, V30, A1/A2) describe sequential and application performance for media workloads. They do not describe how a card behaves when power is removed mid-write, and they do not describe endurance under small steady writes. For a panel, those two properties matter far more than the badge.

What to ask for instead:

• Controller and firmware behaviour on power loss. Ask the supplier to describe, in writing, what the controller does when power is removed during a write — does it complete the current block, discard it, or leave the file allocation table in an intermediate state?
• Endurance class or TBW figure, if the supplier publishes one. If they do not, ask what NAND type the card uses (SLC, pSLC, MLC, TLC) and what wear-levelling strategy the controller applies.
• Bad-block handling. The article on bad block handling — what the controller does explains why a card with a good controller can outlast a card with better raw NAND.
• Operating temperature. Panels often sit in cabinets that run warm. Ask for the card’s rated temperature range and test in the actual enclosure.

This is also where the industrial-grade versus retail-grade distinction lives. A retail card optimised for a phone camera is tuned for burst writes and benign power-down. An industrial card is tuned for sustained small writes and abrupt power loss. The two are not the same product even when the capacity label matches.

Check 5 — Decide whether a card is even the right storage

Before locking a microSD card into the BOM, confirm that removable storage is the right architecture. Many modern panel designs use embedded eMMC instead, because it removes the connector, the card-detect logic and the field-swap failure mode. JEDEC defines the eMMC standard (jedec.org), and the trade-offs are real.

The article on microSD card vs embedded eMMC — which storage for portable devices covers the comparison. The short version for panels:

• Choose microSD if the card must be field-replaceable, if the panel ships in variants with different storage sizes, or if the update procedure is “swap the card”.
• Choose eMMC if the storage is fixed, if the panel is sealed, or if you want to eliminate the connector as a failure point.

If you are already committed to microSD, the article on card vs module — not interchangeable is worth reading before you assume a card and a module of the same capacity behave the same way.

Check 6 — Lock the BOM entry as a specification, not a model name

This is the check that most procurement teams skip, and it is the one that causes the most expensive field failures. Flash vendors revise controller and NAND internals without changing the retail name. A card you qualified in 2026 may behave differently in 2028 even though the label is identical.

Lock the following in the BOM entry:

1. Supplier and manufacturing site. Not just the brand — the actual fab or assembly site if the supplier will disclose it. The article on flash memory lot traceability and die marking explains why this matters.
2. Controller family and firmware revision. Ask the supplier to commit to a controller family and to notify you of firmware changes.
3. NAND type and grade. SLC, pSLC, MLC or TLC, and the grade (industrial, extended, commercial).
4. Capacity and file system as shipped. State whether the card ships pre-formatted and in which file system.
5. Power-fail behaviour as tested. Reference the test you ran on the sample and the result.
6. Change-notification clause. A contractual requirement that the supplier notifies you before changing controller, NAND or firmware, with a sample for re-qualification.
7. Part number and date/lot code on the card. So that a field return can be traced back to a production lot.

If the supplier will not commit to items 2, 3 and 6 in writing, that is a signal about how they will behave when the internals change. The article on how to tell a real Chinese flash factory from a trading company covers how to read that signal.

Check 7 — Test the sample against the panel, not against a benchmark

A speed benchmark tells you almost nothing about whether a card will survive in a panel. The tests that matter are:

• Power-cycle loop. Cut power mid-write, repeatedly, and check that the file system mounts and the last complete record is intact. Run at least a few hundred cycles.
• Sustained write at your real logging rate. Not a burst benchmark — the actual bytes per second the panel writes, for the length of a shift.
• Temperature soak in the actual enclosure. Panels run warm; a card rated for 0–70 °C may be fine on a bench and marginal in a sealed cabinet.
• Fill-level test. Run the card to 80–90% full and confirm the panel’s write latency does not degrade unacceptably, since wear-levelling headroom shrinks as the card fills.
• File-system read-back. Confirm the panel can read back a file it wrote, not just mount the card.

The article on flash sample fee and what to test on one covers the commercial side of getting a sample; the sample acceptance checklist covers the test plan.

Record the failures, not just the passes. A single card that survives 500 abrupt power cuts tells you more than a benchmark that reports a number.

Purchase-order checklist for industrial panel microSD cards

The following is written as numbered prose you can read and act on. It is not a form to fill in; it is a sequence of decisions to confirm before the PO is released.

1. Confirm the capacity band against measured log volume. The firmware team has provided a bytes-per-day figure and a field-service interval, and the chosen capacity leaves at least 50% free space at end of life. If the number is not measured, the PO waits.
2. Confirm the file system against the host firmware build. The exact firmware version that will ship has been tested mounting and reading back a file in the chosen file system. If the host is FAT32-only, the capacity is ≤32 GB. If the host supports exFAT, the test result is recorded.
3. Confirm the host controller’s limits in writing. Maximum capacity, bus mode, card-detect behaviour, power sequencing and flush handling are documented by the board or SoC vendor, not assumed.
4. Confirm the card’s power-fail behaviour with a test result. A power-cycle loop has been run against the actual panel, and the result — including any failures — is on file.
5. Confirm the endurance specification. The supplier has stated the NAND type and grade, and the controller’s wear-levelling approach, in writing. If they publish a TBW or endurance class, it is recorded.
6. Confirm the operating temperature range against the enclosure. The card’s rated range covers the measured internal cabinet temperature at the panel’s worst-case ambient.
7. Lock the BOM entry as a specification. Controller family, NAND type and grade, firmware revision, capacity, file system as shipped, and part number are all in the BOM, not just the retail model name.
8. Secure a change-notification clause. The supplier has agreed in writing to notify you before changing controller, NAND or firmware, and to provide a re-qualification sample.
9. Confirm the date/lot code is on the card. Field returns can be traced to a production lot, and the lot can be traced back to the supplier’s records.
10. Confirm the incoming inspection plan. A defined sample size from each lot is tested for capacity, file-system mount and a short power-cycle loop before the lot is released to production.
11. Confirm the second-source plan, or accept single-source risk explicitly. If the card is single-sourced, the risk is documented and accepted by the product owner, not left implicit.
12. Confirm the commercial terms. MOQ, lead time, deposit and payment schedule are agreed and reflected in the PO. The article on how much deposit — payment schedules explained covers the commercial side.

If you are sourcing custom-branded cards for a panel product line, the WINTEL TF card page describes the formats available, and you can request a quote once the specification above is settled.

What WINTEL can and cannot confirm for you

WINTEL manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM and ODM buyers. For an industrial panel project, that means WINTEL can quote to a specification you provide — capacity, file system as shipped, branding and packaging — and can supply samples for your bench testing.

What WINTEL does not publish, and what this guide therefore does not claim, is a specific speed class, endurance rating, TBW figure, operating temperature range, MOQ or lead time for industrial panel cards. Those are project-specific and must be confirmed in writing against your specification. Do not assume a WINTEL card meets a particular industrial rating until the quotation and specification sheet say so.

The article on how long a custom microSD order takes covers the timeline once a specification is agreed.

FAQ

What capacity microSD card should I standardise on for an industrial HMI? Most panels need 8 GB to 32 GB because they store recipes, logs and firmware images, not media. Staying at or below 32 GB keeps you in SDHC territory, which most embedded host controllers and FAT32 drivers handle without extra work. Go above 32 GB only if you have measured the log or recipe volume and confirmed the host firmware supports SDXC and exFAT.

Should I use FAT32 or exFAT? FAT32 is the safest default for industrial panels because the widest range of embedded OS images and vendor firmware can mount it. exFAT removes the 4 GB per-file limit and the 32 GB volume limit, but it depends on the host having an exFAT driver, which is not guaranteed in older or stripped-down firmware. Test the exact firmware build before you commit a BOM to exFAT.

Do I need an industrial-grade card rather than a retail card? For panels that write logs continuously, cycle power daily, or sit in a warm cabinet, a card built for industrial use is the safer choice. What matters is the controller’s power-fail and wear handling, not the retail speed rating. Ask for the card’s power-loss behaviour and endurance class in writing rather than relying on the marketing name.

Can I lock a single card model into my BOM? Yes, but lock the full specification, not just the model name — controller family, NAND type, firmware behaviour, part number and a change-notification clause. Flash vendors revise internals without changing the retail name, and an uncontrolled swap can change power-fail behaviour in a panel that never moves.

How do I test a sample before releasing a production order? Run a power-cycle loop, a sustained write test at your real logging rate, and a temperature soak in the cabinet you actually ship. Record failures, not just successes. A single card that survives 500 abrupt power cuts tells you more than a speed benchmark.

Sources

• SD Association — SD Specifications and Capacity/Speed Class definitions: https://www.sdcard.org/downloads/pls/ (accessed 2026-11-07)
• SD Association — organisation root, file system guidance: https://www.sdcard.org/ (accessed 2026-11-07)
• Microsoft Learn — FAT32 maximum volume and file size: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-size (accessed 2026-11-07)
• Microsoft Learn — exFAT file system overview: https://learn.microsoft.com/en-us/windows-hardware/drivers/storage/exfat-file-system (accessed 2026-11-07)
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html (accessed 2026-11-07)
• JEDEC — memory device standards portal: https://www.jedec.org/ (accessed 2026-11-07)