Block-level image flashing is not the same as copying files. What to specify, why full-capacity testing has to happen before flashing rather than after, and how per-unit verification actually works at volume.
Yes — a bootable image can be written to microSD cards at the production stage, provided the order is specified as block-level flashing rather than file copying. The sequence must be full-capacity test, then flash, then per-unit read-back verification, because a firmware test needs an empty card. Ask for the per-unit pass rate and the verification method in writing.
Yes, and the request is routine — but only if it is specified as block-level flashing rather than as file copying. The two look similar on an enquiry form and are different operations on the production floor. Flashing writes an image over the whole card from block zero, including the partition table, the bootloader and every file system; copying files leaves the existing layout alone and drops content into it. A card that boots a device needs the first; a card that carries a catalogue needs the second.
The consequence buyers usually miss is one of ordering. A full-capacity test has to fill the entire device, so it has to run on an empty card. Flash first and the test no longer covers the full address space — the capacity report still prints, it just stops proving what it appears to prove.
What changes on the production line
A normal card order runs: incoming component check, assembly where applicable, full-capacity write-and-read-back test, appearance check, packing, shipment.
A flashed order inserts two steps between the test and packing, and they sit there for a reason rather than by preference.
| Stage | Normal order | Flashed order |
|---|---|---|
| Full-capacity test | Yes | Yes — still on empty cards |
| Image write | — | Added |
| Per-unit read-back verify | — | Added |
| Appearance and packing | Yes | Yes |
| Shipment | Yes | Yes |
Two additions, and both are serial. That is the part that affects a delivery date: writing and verifying 1,000 cards does not run in parallel with anything else, and it cannot be pulled forward into the assembly stage.
Decision one: supply an image the factory can write, not a folder of files
An image is a single binary file representing the entire card. The factory needs that file, its checksum, and a statement of the minimum card size it fits on.
A stated size. An 8GB image does not fit an 8GB card once the real usable capacity, always below the marketing number, is taken into account. State the image size in bytes, not the nominal card size.
A checksum for the image itself. The factory should confirm the file it received matches the file you sent before writing it to anything. Without this, a corrupted transfer becomes 1,000 identically wrong cards.
A decision on first-boot expansion. If the image is smaller than the card, an unexpanded file system leaves usable space on the table. Whether that space is recovered on first boot, left unallocated, or pre-expanded during flashing is a choice that has to be made before production.
Decision two: decide whether the card must also pass a capacity test
This is the ordering question that causes the most rework, and it belongs in the purchase order rather than in a later conversation.
Two sequences work:
- Test, flash, verify. The card is proven at full capacity while empty, then written, then read back. The capacity report covers the hardware; the verification covers the content. Ask for this one.
- Flash, verify, test what remains. Acceptable only when the image is small relative to the card and the buyer accepts that the test covers the unallocated region rather than the whole device. Cheaper in time, weaker as evidence.
Testing after flashing and calling it a full-capacity test does not work. The test writes over the payload, so the payload has to be restored afterwards, and the report describes a state the customer never receives.
Decision three: verification that means something
A card that mounts and shows the right folder structure proves very little. A damaged bootloader, a partition table written from a truncated image, or a card that failed partway and was silently retried can all leave the file system perfectly readable.
| Method | What it covers | Cost | Blind spot |
|---|---|---|---|
| Mount and inspect | File system only | Minutes at volume | Partition table, bootloader, unwritten tail |
| Partition-level hash | The payload partition | Moderate | Damage outside the partition |
| Full-card read-back hash | Every block | Highest | None, other than time |
At volume this is a function of the duplicator rather than of human attention, so the question is not “do you verify” but “what does the machine report, and can I see a run report”.
Decision four: what to ask about the pass rate
Every flashed batch has failures. Cards get rejected, reflashed, rejected again. A buyer needs the rate, and the rule for the units that fail twice.
- First-pass yield on the batch, as a percentage.
- The disposition rule for cards that fail twice — scrapped, downgraded, or returned to stock. A card that fails twice should not appear in the shipment because the third attempt happened to pass.
A supplier who reports a plausible yield and a stated disposition rule is running a process. One who reports “no failures” is either not measuring or not telling.
Decision five: whether the image is confidential
An image that contains a licence key, a device certificate or customer data is not the same asset as a folder of marketing PDFs, and it should not be handled the same way.
Three arrangements, in increasing order of control:
Delete after the run. The factory writes the image, then confirms in writing that the master is deleted and not retained for reorders. A fresh copy is supplied each time. Adequate for images that are recoverable from the buyer’s own build system.
Encrypted handover. The image arrives as an encrypted archive, the key travels by a different channel. This removes casual exposure; it does not stop a determined party with production access.
Ship empty, flash locally. The cards travel unflashed and are written at the buyer’s own premises. This is the right answer when the image is regulated, when volumes are small enough for a local process, or when the buyer already runs a duplication step as part of device assembly. It is a normal arrangement, not an unusual request.
When this should not be done at the factory
Small volumes. Below a few hundred units, the setup charge dominates and a local duplicator is cheaper. The crossover depends on the setup cost quoted, so the comparison is arithmetic rather than principle.
Images that change often. Flashing sits at the end of the production sequence. An image revised weekly will collide with a schedule fixed weeks earlier, and the collision is discovered at packing.
Images the buyer cannot hand over. If the content cannot leave the buyer’s premises under any arrangement, ship the cards empty. For regulated payloads that is the correct process, not a compromise.
Orders that need device-level testing after flashing. If the card has to be proven in the finished device rather than on a bench, that test belongs wherever the device is assembled.
The short version
If you are about to ask for a flashed batch, settle these before the enquiry:
One image file, its byte size, and its checksum. Not a folder, not a link, not a nominal card size.
A stated sequence: full-capacity test, then flash, then verify. Written into the order, because the default is ambiguous.
Full-card read-back verification, per unit. Sampling checks the process; only per-unit verification checks the card.
First-pass yield and the rule for second failures. Both in writing.
A confidentiality arrangement chosen from three options. Delete, encrypt, or ship empty.
The flashing itself is not the difficult part. The difficult part is that it happens last, in series, after everything else has already been decided.
Frequently asked questions
How much does image flashing add per card?
It is priced as a step, not as a material, so the per-unit figure falls as volume rises while the setup charge does not. The variable cost is dominated by write time, which depends on card speed and image size rather than on quantity. Ask for the setup charge and the per-unit charge separately, and ask what image size the per-unit figure was calculated against — a quote that does not state the image size is not comparable with one that does.
Will flashing invalidate the capacity test report?
Not if the report was produced before flashing, and that is the sequence to insist on. It will invalidate a report produced afterwards, because a full-capacity test fills the device and overwrites the payload. If a supplier proposes to test after flashing, the report describes a card state the buyer never receives, and the payload has to be written again after the test anyway.
How long does a 1,000-card batch take to flash and verify?
It scales with image size, card speed and verify speed, and the verify pass reads the whole card back, so it is not a rounding error. The practical question is not the raw figure but whether the quoted lead time was calculated with the flashing step included, because a schedule built from assembly and packing alone will slip at the end.
Can the cards be flashed and then packed individually?
Yes, and the order matters: verification has to happen before packing, because once a card is sealed into a retail pack the read-back requires unpacking it again. For bulk-packed orders this is trivial. For printed or individually packed orders, confirm that verification runs on the loose card and the pack is built afterwards.
What happens to cards that fail verification?
They should be reflashed once and re-verified. A card that fails twice should be removed from the batch rather than retried until it passes, because the retry that succeeds is not evidence that the underlying card is sound. Ask for the disposition rule in writing — scrapped, downgraded, or returned to stock — before the order, not after the first disputed shipment.
Does the file system on the image matter to the factory?
Only in that the factory cannot change it. The image defines the partition table and the file systems inside it, so a request to “use a different format” is a request to rebuild the image, not a production instruction. Decide the layout in the build, confirm the image boots on a sample card, and send that.
Frequently asked questions
How much does image flashing add per card?
It is priced as a step, not as a material, so the per-unit figure falls as volume rises while the setup charge does not. The variable cost is dominated by write time, which depends on card speed and image size rather than on quantity. Ask for the setup charge and the per-unit charge separately, and ask what image size the per-unit figure was calculated against — a quote that does not state the image size is not comparable with one that does.
Will flashing invalidate the capacity test report?
Not if the report was produced before flashing, and that is the sequence to insist on. It will invalidate a report produced afterwards, because a full-capacity test fills the device and overwrites the payload. If a supplier proposes to test after flashing, the report describes a card state the buyer never receives, and the payload has to be written again after the test anyway.
How long does a 1,000-card batch take to flash and verify?
It scales with image size, card speed and verify speed, and the verify pass reads the whole card back, so it is not a rounding error. The practical question is not the raw figure but whether the quoted lead time was calculated with the flashing step included, because a schedule built from assembly and packing alone will slip at the end.
Can the cards be flashed and then packed individually?
Yes, and the order matters: verification has to happen before packing, because once a card is sealed into a retail pack the read-back requires unpacking it again. For bulk-packed orders this is trivial. For printed or individually packed orders, confirm that verification runs on the loose card and the pack is built afterwards.
What happens to cards that fail verification?
They should be reflashed once and re-verified. A card that fails twice should be removed from the batch rather than retried until it passes, because the retry that succeeds is not evidence that the underlying card is sound. Ask for the disposition rule in writing — scrapped, downgraded, or returned to stock — before the order, not after the first disputed shipment.
Does the file system on the image matter to the factory?
Only in that the factory cannot change it. The image defines the partition table and the file systems inside it, so a request to 'use a different format' is a request to rebuild the image, not a production instruction. Decide the layout in the build, confirm the image boots on a sample card, and send that.