October 07, 2026

An Engaging Story- Enjoy the Ride- SD Card Thriller- Step Inside ..

Twenty files sat on the Insta360 X5's card, just shy of 30 gigs of 360 footage. The biggest was a single 13.7 GB clip. I copied all of it to the 1 TB NVMe on the Mac, checked that every file landed the same size it was on the card, then put the card back in the camera and formatted it.

Back in the Mac, the card came up exFAT- the format the X5 picks for itself.

Format It Where It Lives

Formatting in the camera or drone writes the file system that device wants and the folder layout it expects, both in one go.

The X5 wants exFAT on a card up to 1 TB, rated UHS-I and V30 or faster. UHS-I is the bus the card talks over; V30 is the "video speed class", a promised minimum write speed of 30 MB a second while recording. Insta360 lists the camera and the Insta360 app as the places to format. A computer works too as long as the result is exFAT- a card in any other format gets an error from the X5 asking for exFAT. The X5's SD card menu also has a Low-Level Format, which wipes the whole card top to bottom. Insta360 says it can help performance a bit.

The card in my X5 is 32 GB. On the SD Association's capacity table a 32 GB card is SDHC, and SDHC cards ship FAT32. The X5 formatted it exFAT anyway. Insta360 also says 32 and 64 GB cards trigger "insufficient card speed" warnings more often, and recommends 128 GB or bigger.

Why Every Card Has a DCIM Folder

DCIM comes from DCF, the Design rule for Camera File system standard. DCIM stands for "digital camera images". DCF also limits camera cards to the FAT family: FAT12, FAT16, FAT32 or exFAT. The X5 uses the DCIM folder but names the folder inside it Camera01, where DCF calls for a numbered name like 100ABCDE.

DJI Drones

DJI's help pages format the card through the DJI Fly app: from the camera view, System Settings, then Camera, then Format. The resulting format depends on the model. The Mini 3 and Mini 2 SE list FAT32 for cards 32 GB and under and exFAT above that. The Mini 4 Pro, Mini 5 Pro, Avata 2, Air 3S, Mavic 3 Pro, Mavic 4 Pro and Flip list exFAT only. Formatting in the drone or the app gets the right one for that model without looking it up.

DJI also says to copy the footage off before formatting, and not to pull the card while the drone is recording. The claim that formatting on a PC makes a DJI drone act up shows up on forums- I couldn't find it in anything DJI published.

Card Size Picks the Factory Format

A new card's factory format depends on its capacity class. The SD Association, the group that writes the SD standard, defines four classes:

SDHC cards, up to 32 GB, ship FAT32. SDXC cards, anything over 32 GB (48 GB cards included, not just 64 and up), ship exFAT.

FAT32 can't hold a single file bigger than 4,294,967,295 bytes- one byte short of 4 GiB. A GiB is the "binary" gigabyte, 1024 x 1024 x 1024 bytes, a bit more than the billion bytes a GB on the package means. The 13.7 GB clip off my X5 could not exist as one file on FAT32. exFAT tracks file size with 64 bits instead of 32... no video file comes anywhere near that limit.

The SD Association chose exFAT when it announced SDXC in January 2009. Microsoft's press release that December, opening exFAT up for licensing, quoted the SD Association.

A 15 MB drive from some gadget was plugged into the Mac too, holding a couple of .bmp screenshots. The Mac reported it as FAT12- floppy disk era. FAT12 dates to 1980 and QDOS, the "Quick and Dirty Operating System" Microsoft bought and turned into MS-DOS. It still turns up in 2026 on drives too small to need anything newer.

The ESP32 Is Stuck on FAT

ESP32 SD card code expects FAT32. A 64 GB card off the shelf is exFAT. The ESP32 won't mount it- on the Arduino side SD.begin() returns false, and Espressif's own SD card example states in its readme that it only mounts FAT32 cards. FAT16 works on small old cards too.

The first answer I got for why was memory. The original ESP32 has 520 KB of SRAM (the chip's working memory), and only 320 KB of it holds data. A file system built for terabytes sounded like too much for it.

SdFat, a separate SD card library, puts numbers on it. In a small test sketch on an Arduino Uno, exFAT support costs about 9.5 KB more flash and 53 bytes more RAM. On an ESP32 board with megabytes of flash, that's rounding error.

Espressif's stated reason is licensing. ESP-IDF, Espressif's official framework (the Arduino ESP32 core is built on it), reads SD cards with FatFs, a small open source library written by a developer who goes by ChaN. FatFs supports exFAT behind one config line, FF_FS_EXFAT. Espressif ships that line set to 0 in every release from v5.0 through v6.1, with no menuconfig option for it (menuconfig is ESP-IDF's settings menu). ESP-IDF's docs say there's no supported way to turn exFAT on, and to check the licensing first. From an Espressif engineer, answering one of many GitHub requests for exFAT:

usage of exFAT implementations in many cases requires a license from Microsoft.

ChaN's FatFs docs say the same thing- exFAT is a Microsoft patent, and a commercial product that enables it may need a license.

Microsoft published the exFAT spec in 2019 and backed adding exFAT to the Linux kernel. Linux got a staging driver in 5.4 (staging is where not-yet-finished kernel drivers live), then Samsung's driver replaced it in 5.7. In October 2020 the Open Invention Network added exFAT to its patent non-aggression agreement, a promise among its members not to sue over it. That agreement covers Linux. In one GitHub thread someone pointed Espressif to Microsoft's 2019 announcement; Espressif replied that the OIN cover applies to Linux, not to a separate exFAT implementation in microcontroller firmware.

On plain ESP-IDF, exFAT can be switched on by editing that config line and a couple of related ones- unsupported, with the licensing question left to whoever ships it. The Arduino core ships ESP-IDF as precompiled libraries. Changing the setting there means rebuilding those libraries with Espressif's lib builder. Even then, the Arduino File API is 32-bit, with file size and seek topping out at 4 GiB- the same ceiling as FAT32.

exFAT With SdFat

Bill Greiman's SdFat library supports exFAT on the ESP32 out of the box. It's on by default for every board except small AVR chips like the Uno's. Someone ran its exFAT logger example on an ESP32 with a 64 GB exFAT card; the crash they hit was the task's stack size (the scratch memory a task gets), not the file system. On the ESP32, SdFat appears to use SPI only (the four-wire hookup most breakout boards use) rather than the faster 4-bit SDMMC mode some ESP32 chips have. Its File type clashes with the ESP32 core's own File; use FsFile instead. SdFat itself is MIT licensed. Whether a product using exFAT needs a Microsoft license is a separate question.

FAT32 on a 64 GB Card

A 64 GB card works on the ESP32 once it's FAT32. It's off-spec, since SDXC is "supposed" to be exFAT, but the ESP32 doesn't check. Espressif's SD example can format a 64 GB card to FAT32 by itself with format-if-mount-failed turned on. That option formats any card it can't mount, with no prompt- a camera card put in by mistake loses its footage. Turn it off once the card is done.

The card also needs an MBR partition table, not GPT. A partition is a slice of a card with its own file system, and the partition table is the map of those slices. MBR (Master Boot Record) is the older table from the DOS days. GPT (GUID Partition Table, "GUID Partition Map" in Disk Utility) is the newer one Macs default to. ESP-IDF builds FatFs without GPT support. It only reads MBR; a GPT card won't mount.

Long Logs and Power Loss

FAT32's 4 GiB per-file cap matters for long-running loggers. At 100 KB a second a single log file reaches it in about 12 hours; at 1 MB a second, about 72 minutes (my arithmetic). Starting a new file by size or by day avoids it. Deleting a file while it's still open can corrupt the file system, according to ESP-IDF's docs.

FAT also has no protection against power loss. Anything written since the last sync can be lost, and ESP-IDF's docs name sudden power-off as FatFs's biggest weakness. Boards get unplugged mid-write on benches all the time- on purpose, or by a foot catching the USB cable. On the Arduino core, flush() writes through to the card (an old bug report covers a time when it didn't). It's slow; every few seconds works better than after every line.

Pi 5- Let the Image Do It

A Pi 5 boot card doesn't need formatting first. Raspberry Pi Imager writes the whole OS image over the card, partition table and all, replacing whatever was there. The image comes with two partitions: a 512 MiB FAT32 one called bootfs, and an ext4 one called rootfs (ext4 is the standard Linux file system).

The boot partition is FAT32 because the Pi's bootloader, the first code that runs and goes looking for the OS, loads from a FAT partition. Raspberry Pi's boot docs say so in the NVMe boot section. In 2017 a Raspberry Pi engineer said the firmware couldn't read a card because it was exFAT; that was an older Pi. I couldn't find an official statement on whether a Pi 5 can boot from exFAT. Every Raspberry Pi OS image ships FAT32 for boot.

Plugged into a Mac, a Pi card shows only the small FAT32 bootfs; macOS can't read the ext4 rootfs. Windows sees the ext4 partition, can't read it, and offers to format it. Clicking Format wipes the Pi's OS- cancel it. The SD Card Formatter's Format Size Adjustment returns a Pi card to its full size. Raspberry Pi Imager's Erase option also wipes a card to a single FAT32 partition on MBR, at any size.

Data Drives on the Pi

For a drive that stays on the Pi, ext4 suits Linux best, file permissions included. For a drive that goes back and forth between the Pi and a Mac, exFAT is the format both can read and write without extra software. The Pi 5 kernel includes an exFAT driver as a module (a driver the kernel loads when needed). An exFAT drive should mount as is. Raspberry Pi's external storage docs still say to install exfat-fuse- those docs look older than the kernel config. Formatting exFAT on the Pi needs the exfatprogs package. It doesn't appear to be in the standard image. The Mac formats exFAT without it.

Doing It on the Mac

Making a FAT32 card in Disk Utility, for an ESP32 or anything else that needs FAT32:

View, then Show All Devices. Without it, Disk Utility lists only the volume (the file system on the card), not the card itself, and the Scheme menu in step 5 doesn't appear.
Select the card- the top line of its tree, not the volume indented under it. Check the size matches the card.
Erase. Name it in capitals, 11 characters at most, no spaces (FAT's limit).
Format: MS-DOS (FAT). On a Mac that makes FAT32 on a 64 GB card (a very small card may get FAT16, which the ESP32 also reads). Apple's help pages recommend exFAT over 32 GB but don't block FAT32.
Scheme: Master Boot Record. Apple's general erase steps say GUID Partition Map, which adds a hidden 200 MB EFI partition (a small partition computers boot from). The ESP32 can't read GPT.

From Terminal, list the external drives:

diskutil list external

Then erase the card, with its disk number in place of diskN:

diskutil eraseDisk FAT32 ESP32 MBRFormat /dev/diskN

eraseDisk doesn't ask for confirmation. Pointed at the wrong disk, it wipes that disk with no undo. Tonight there were four drives on this Mac: the X5 card, the NVMe holding all the footage, a card from an Android phone, and the FAT12 gadget- four disk numbers a typo apart. Unplugging every drive that isn't needed, especially the one with the only copy of anything, removes that risk. Listing before and after plugging in the card shows which entry is new; that's the card. Use the whole disk (disk4), not a partition (disk4s1). Disk numbers can change when something is plugged in or the Mac restarts. List again right before erasing, and check the size next to the number twice. eraseDisk unmounts the card itself; if it reports it couldn't, close any Finder window showing the card and run it again.

macOS also writes hidden files to FAT and exFAT cards: ._ files next to regular files, and folders such as .Spotlight-V100 and .Trashes. ESP32 code that walks the card's folders, an MP3 player or a photo frame for example, will pick up ._song.mp3 as a song. dot_clean -m /Volumes/ESP32 deletes the ._ files. Eject the card before pulling it.

The SD Card Formatter and FAT32

The SD Card Formatter picks the file system from the card's capacity class, with no setting to change it. A 64 GB card always comes out exFAT. That's right for cameras. For a 64 GB ESP32 card, use Disk Utility, Terminal or Raspberry Pi Imager's Erase instead.

Windows' 32 GB limit on formatting FAT32 belongs to its formatter; Windows reads larger FAT32 cards. Windows 11 Insider builds are raising the command-line limit to 2 TB. The regular format window reportedly still stops at 32 GB. Raspberry Pi Imager's Erase makes an MBR, FAT32 card at any size on Windows too.

Before formatting any card with footage on it, check the copy- file sizes at least, checksums for certainty (shasum on the Mac). The NVMe had two copies of the X5 footage. One had all twenty files; the other was four short. That got caught before the card was wiped.

Running exFAT on an ESP32 through SdFat in something real, or got a camera or drone that's picky about cards? Leave a comment.

Links-
SD Card Formatter: https://www.sdcard.org/downloads/formatter/
Insta360 X5, formatting the card: https://onlinemanual.insta360.com/x5/en-us/camera/basicuse/formatting
SdFat, for exFAT on the ESP32: https://github.com/greiman/SdFat
Raspberry Pi Imager: https://www.raspberrypi.com/software/

Glossary

FAT12 / FAT16 / FAT32 — the File Allocation Table family of file systems, named for the size of each table entry (FAT32 actually only uses 28 of its 32 bits). FAT32 is the one nearly everything can read; it caps single files one byte short of 4 GiB.
exFAT — Microsoft's newer member of the FAT family, built for flash cards. 64-bit file sizes, so no practical file size limit. Patented by Microsoft.
ext4 — the standard Linux file system. Raspberry Pi OS keeps its root partition on it.
APFS — Apple File System, the format Macs use for their own drives.
GiB / GB — a GiB is 1024 x 1024 x 1024 bytes; a GB on a card's label is 1,000,000,000 bytes.
SDSC / SDHC / SDXC / SDUC — the SD Association's capacity classes: up to 2 GB, over 2 to 32 GB, over 32 GB to 2 TB, over 2 TB to 128 TB.
UHS-I / V30 — UHS-I is the card's bus (how it talks to the device); V30 is a video speed class promising a minimum write speed of 30 MB a second.
Partition — a slice of a card or drive that holds its own file system. One card can have several.
Master Boot Record (MBR) — the older, simpler way of describing a card's partitions. What the ESP32 needs.
GUID Partition Map (GPT) — the newer partition scheme Macs use. When a Mac erases a disk this way it adds a hidden EFI partition.
Allocation unit — the size of the chunks a file system hands out. Also called cluster size.
bootfs / rootfs — the two partitions on a Raspberry Pi OS card: a small FAT32 one the Pi boots from and the ext4 one holding the OS.
Bootloader — the first bit of code that runs on power-up and goes looking for the operating system.
DCF / DCIM — the Design rule for Camera File system standard, and the "digital camera images" folder it puts on every camera card.
ESP-IDF — Espressif's official development framework for ESP32 chips. The Arduino ESP32 core is built on top of it.
FatFs — a small open source FAT/exFAT library by ChaN, used by ESP-IDF and many other microcontroller projects.
SdFat — Bill Greiman's SD card library for Arduino boards, with exFAT support built in.
SPI / SDMMC — two ways an ESP32 talks to an SD card: SPI over four wires (simple, common on breakout boards) or the SD card's own 1-bit/4-bit SDMMC bus (faster, on the chips that have it).
Kernel module — a driver Linux loads only when it's needed.
AppleDouble (._ files) — hidden files macOS writes next to your files on FAT and exFAT drives to hold Mac-only metadata.

Sources