microSD Works in a Reader but Resets in the Device: What to Test

A microSD card that passes in a USB reader can still disappear, reset or produce I/O errors in its target device. The reader and device use different sockets, power paths, controllers, firmware and workloads. Neither result alone proves that the card or host is defective. Start by recording where and when the failure occurs, then change one variable at a time.

This guide is for a repeatable integration fault. It does not replace the target device's electrical specification or authorize probing a live board without a qualified engineer and suitable test points.

Record the event before replacing parts

“Card failed” is too broad for diagnosis. Record whether the device failed to detect the card at power-on, lost it after a write, remounted it, reported a command timeout, or could still read but no longer write. Note the host hardware and firmware revision, card identity and lot, bus mode, supply source, temperature, fill level and active application task. Preserve logs with timestamps. A power interruption, failed command and filesystem error can occur in sequence; their order matters.

KIOXIA's handling manual warns about removing the card or power during access. Its warning is a reason to preserve the state and data after a failure, not proof that every reported filesystem error began with power loss.

Swap one card and one host at a time

Run the same firmware and workload in each combination. A known working reference should be a documented card configuration, not simply a different capacity. Use fresh copies of test data if a full-address write test would erase evidence from the failing sample.

Combination	What it can show	What it cannot prove
Candidate card + failing host	Reproduces the original event and provides a baseline	Which component caused it
Reference card + failing host	Whether the event also occurs with another card	That the first card is defective if the reference passes
Candidate card + second host of the same revision	Whether this host unit is unusual	That the design is sound across all units
Candidate card + USB reader	Whether the sample shows a reader-visible fault	That the target host supplies stable power or handles its bus mode correctly

Repeat a failing combination enough times to characterize intermittency, but set the test duration from the actual failure pattern. Record card insertion and reseating; a result that changes after reseating makes the socket and contact path a useful next hypothesis. Do not call it a contact defect without inspection and corroborating evidence.

Test the power hypothesis safely

The SD Association overview lists a 2.7–3.6 V operating range for the first-row 3.3 V VDD supply and describes separate low-voltage signaling and additional supplies for applicable modes. Identify the card and interface before choosing a limit. A nominal reading at the regulator while idle does not establish the voltage seen near the card during the failing operation.

A hardware engineer can use the host schematic and designed board test points near the socket to capture the relevant supply and ground during the exact event, then align that trace with host logs. The measurement setup and bandwidth must be appropriate for the event. Do not place loose probes or improvised wires on card contacts. If the board has no safe observation point, document that limitation and use an approved engineering fixture or board revision.

The Microchip USB2641 checklist includes card-detect and supply-capacitance checks for that controller design. It illustrates questions to ask about a host; its component choices are not a universal microSD circuit prescription. Compare the measured behavior with the target host's design limits and the identified card's requirements. An observed dip near a failure is a lead; timing and a controlled change are still needed to establish cause.

Keep alternative causes open

Observation	Next evidence to collect
Failure follows one host unit after card swaps	Socket inspection, supply event, card-detect state and host logs
Failure follows a card sample across target hosts	Sample identity, full-address verification on a copy-safe test sample, and card/host command logs
Errors appear only in a faster bus mode	Host timing, mode negotiation and firmware configuration
Filesystem reports corruption after a reset	Earlier bus and power events, then file-level integrity and recovery behavior
Failure changes after reinsertion or vibration	Contact condition and mechanical retention under the intended environment

CRC errors, timeouts and remounts can arise from several mechanisms. Do not infer NAND wear from a CID or other identity field, and do not infer a stable card supply from a reader pass. If power evidence is within the agreed design envelope, investigate signal timing, driver recovery and media behavior instead of repeatedly changing capacitors.

Send a reproducible case to the supplier

Share the exact card identifier and lot, target host revision, firmware, event sequence, log timestamps, swap results, environmental conditions and any safely captured electrical evidence. State which test erased the card and preserve an untouched failing sample when possible. Agree on the acceptance criterion and who owns host changes, card configuration changes and further samples before repeating a trial.

A quote request can reference the qualified configuration and projected volume once the fault is resolved. A reader pass is useful screening evidence; release for a device still depends on the target host and its real workload.