Why FatFs Returns FR_NO_FILESYSTEM on a Properly Formatted SD Card – MBR/DBR Insights

Background

Last year a GPS path recorder stored data on a TF card using the FatFs library. After a period of neglect the device stopped working, returning the error FR_NO_FILESYSTEM during read/write operations.

Environment

MCU: MSP430F5418

SD Card: SanDisk 1 GB T‑Flash

Interface: hardware SPI

FatFs version: 0.09

Problem

On a PC the SD card reads and writes correctly, but FatFs reports FR_NO_FILESYSTEM. The low‑level SD driver works, so the issue lies in FatFs’s filesystem detection.

Solution

Format the SD card with FatFs’s f_mkfs() function, ensuring the underlying disk_ioctl() implementation is correct; otherwise the card may be mistakenly formatted to a much smaller size.

Upgrade to FatFs version 0.10, which contains a fix for this detection problem.

MBR Overview

The Master Boot Record (MBR) occupies the first 512 bytes of the SD card. The first 446 bytes are boot code, the next 64 bytes form four 16‑byte partition entries, and the final two bytes are the signature 0x55 AA.

Partition Table Details

Each 16‑byte entry describes a partition. Only the bytes at offsets 0x00, 0x04, and 0x08 are relevant for this analysis:

0x00: Partition status (0x00 inactive, 0x80 active).

0x04: Filesystem type (e.g., 0x01 FAT32, 0x06 FAT16, 0x07 NTFS).

0x08: Relative sector count – the LBA of the partition’s first sector.

DBR Overview

The Dos Boot Record (DBR) resides in the first sector of a FAT partition and contains the BIOS Parameter Block (BPB) and extended BPB, which include the string “FAT” when the partition is formatted as FAT.

How FatFs Detects a FAT Filesystem

static BYTE check_fs (FATFS *fs, DWORD sect) {
    if (disk_read(fs->drv, fs->win, sect, 1) != RES_OK) return 3;
    if (LD_WORD(&fs->win[BS_55AA]) != 0xAA55) return 2;
    if ((LD_DWORD(&fs->win[BS_FilSysType]) & 0xFFFFFF) == 0x544146) return 0; // "FAT"
    if ((LD_DWORD(&fs->win[BS_FilSysType32]) & 0xFFFFFF) == 0x544146) return 0;
    return 1;
}

The function reads the specified sector and checks for the signature 0x55AA and the ASCII string “FAT” in the BPB fields. Return values indicate:

Valid FAT partition.

Valid boot record but not FAT.

Invalid boot record.

Disk read error.

Filesystem Check Logic in FatFs

fmt = check_fs(fs, bsect = 0);
if (LD2PT(vol) && !fmt) fmt = 1;
if (fmt == 1) {
    pi = LDPT(vol);
    if (pi) pi--;
    tbl = &fs->win[MBR_Table + pi * SZ_PTE];
    if (tbl[4]) {
        bsect = LD_DWORD(&tbl[8]);
        fmt = check_fs(fs, bsect);
    }
}
if (fmt == 3) return FR_DISK_ERR;
if (fmt) return FR_NO_FILESYSTEM;

If _MULTI_PARTITION is not defined, LD2PT(vol) is always zero, so FatFs only examines the first partition table entry. When the SD card’s partition data happen to be stored in the fourth entry, FatFs fails to find a FAT volume and returns FR_NO_FILESYSTEM.

Root Cause Analysis

The card’s MBR contains the relevant partition information in the fourth entry instead of the first. Windows can still recognize the card because it scans all entries, but FatFs, limited to the first entry, reports no filesystem.

Workarounds

Re‑format the card with FatFs’s f_mkfs() to ensure the partition table is placed in the first entry.

Upgrade to FatFs V0.10, which fixes the detection logic.

Manually edit the MBR/DBR with a hex editor (e.g., WinHex) to move the partition data to the first entry.

Conclusion

The FR_NO_FILESYSTEM error can stem from an MBR layout where the active partition resides in a non‑first entry, a situation FatFs 0.09 cannot handle. Using f_mkfs() or upgrading to FatFs V0.10 resolves the issue, restoring reliable SD‑card access for embedded applications.