Skip to main content

C0-microSD+ Host Compatibility

The C0-microSD+ implements the SD 1.0 and SD-over-SPI protocols for the highest possible compatibility. It presents itself to a host as an unformatted block-storage device over the standard SD interface. Any host that supports the standard SD protocol, in either its 4-wire mode or its SPI mode, enumerates the module without additional drivers. Host compatibility is therefore a question of the mechanical slot and of the host SD controller rather than a question of software support.

Enumeration without drivers

The module speaks the SD protocol the same way an ordinary SD card does, and all communication with it happens through host-initiated block read and write operations. It does not use the SDIO extension of the SD standard, so a host needs no vendor driver, no kernel module, and no firmware patch. An operating system that already mounts SD cards sees the C0-microSD+ as one more block device.

The module enumerates unformatted, because the addresses that a host reads and writes are the registers, buffers, and memory regions of the Signaloid SoC rather than a file system. Do not format the module, and dismiss any host prompt that offers to format it for you. For the transport-level detail, see SD Interface.

Mechanical and electrical compatibility

The C0-microSD+ has the microSD UHS-II outline and measures 11 mm × 15 mm × 0.8 mm, but it drives only the eight SD pads of the first row, so it works in a standard microSD slot and stays hot-swappable. A standard microSD socket contacts the eight pads of the SD interface, which is all that host communication requires. The second pad row of the UHS-II footprint carries the SPI configuration port and the three user GPIOs rather than UHS-II differential lanes, and a host that leaves that row unconnected loses none of the SD functionality.

danger

Do not insert the C0-microSD+ into a host that drives UHS-II signaling on the second pad row. The module does not support such a host, because the UHS-II differential lines interfere with the configuration flash. Use a standard microSD slot, which contacts the eight SD pads of the first row only, or a full-size SD slot reached through a passive microSD-to-SD adapter, which wires only that same first row.

The host supplies 3.3 V on the VDD pad, and the SD pads operate at LVCMOS 3.3 levels. For supply, signal-level, and socket guidance, see Design-In Guide. For the pinout and the mechanical dimensions, see Specifications.

Host categories

The C0-microSD+ works with the following categories of host.

  • Card readers and computers. A USB microSD card reader, or a computer with a built-in card slot, gives you a host for flashing device applications and for running host applications. This is the usual arrangement while you develop.
  • Single-board computers. A spare microSD slot on a single-board computer carries the module over the 4-wire SD protocol, which lets the board offload distributional computation to the module.
  • Programmable logic controllers (PLCs). Industrial controllers with an unused microSD slot host the module without any change to the controller hardware.
  • Microcontroller-based embedded systems. A microcontroller drives the module over SD-over-SPI through an ordinary SPI peripheral, so a design that already has an SPI bus and one spare chip-select line can host the module.
  • Mobile devices. Android mobile devices that have a microSD slot can host the module, provided that the platform grants your application raw block-device access.

Tested SD host controllers

The following card readers, hubs, and adapters present the module to a computer over their own SD host controllers. The Slot column records which slot the module goes into, because that is what decides whether the host is supported.

Host deviceSlotMechanicalSD interface
SD-DevmicroSDYesYes
Kingston MobileLite PlusFull-size SDYesYes
Hoco HB20microSDYesYes
Hama 8in1 TransparentmicroSDYesYes
Ugreen USB C 7in1 HubmicroSDYesYes
UGREEN Micro SD Card ReadermicroSDYesYes
CrowdSupply microSD Card ReadermicroSDYesYes
Sandisk Pro ReadermicroSD, UHS-IIYesNot supported
Sandisk Pro ReaderFull-size SDYesYes
Delock CF adapterFull-size SDYesYes

A host with a UHS-II microSD slot is not supported, because such a slot contacts the second pad row of the module and drives UHS-II differential signaling onto it, which interferes with the configuration flash. The SanDisk reader above is listed twice for that reason. Its microSD slot is UHS-II and must not be used, while its full-size SD slot is safe.

A full-size SD slot is always safe, because the module reaches it through a passive microSD-to-SD adapter. Such an adapter wires only the eight contacts of the first pad row and leaves the second row unconnected, so no UHS-II signaling reaches the module. Use a plain adapter with a single row of contacts, which is what an ordinary microSD-to-SD adapter provides.

Tested platforms

The following computers, industrial controllers, and microcontroller boards carry the module in an integrated slot. The MacBook Pro models have a full-size SD slot, so the module reaches them through a passive microSD-to-SD adapter. The remaining hosts have an integrated microSD slot.

Host deviceSlotMechanicalSD interface
Macbook Pro M1Full-size SDYesYes
Macbook Pro M3Full-size SDYesYes
Macbook Pro M4Full-size SDYesYes
Macbook Pro M4Full-size SDYesYes
Bosch ctrlX core X3 PLCmicroSDYesYes
Wago PFC100 PLCmicroSDYesYes
Wago PFC200 PLCmicroSDYesUntested
Phoenix Contact PLCNEXT PLCmicroSDYesUntested
SparkFun MicroMod AssetTrackermicroSDYesUntested
SparkFun MicroMod-MachineLearning Carrier BoardmicroSDYesUntested
SparkFun DataLogger IoTmicroSDYesUntested
SparkFun QWIIC OpenLogmicroSDYesUntested
SparkFun ThingPlus RP2040microSDYesUntested
SparkFun ThingPlus STM32microSDYesYes
SparkFun OpenLog ArtemismicroSDYesUntested
Adafruit Feather AdaloggermicroSDYesUntested
Adafruit Feather M0 AdaloggermicroSDYesUntested
Beaglebone AImicroSDYesUntested
M5Stack CardputermicroSDYesYes

Host operating system support

Enumeration requires no driver on any supported operating system, but the way you identify the device, the privileges you need for raw block-device access, and the validation status of the flashing toolkit all differ per platform. See Host OS support.

Next steps