ARM嵌入式SD卡驱动实战：从协议机制到文件系统移植-平芜编程栈

搞过ARM嵌入式开发的朋友，十有八九都会跟SD卡打交道。这玩意儿看着不起眼，插上就能存数据，但真要在嵌入式项目里把它跑稳、跑快、跑可靠，里面门道其实不少。网上关于SD卡的资料很杂，要么是纯理论协议分析，要么是某个开发板的例程搬运，很少有把协议要点、驱动编写和实际调试串起来讲的。这篇文章我想把我学习ARM嵌入式过程中，围绕SD卡这块的笔记和踩坑记录整理出来，从协议基础到初始化流程，从数据读写到文件系统移植，再到实际项目中遇到的各种问题，一次性说透。如果你正在学STM32或者类似的ARM平台，想搞懂SD卡到底是怎么工作的，或者项目中正被SD卡读写不稳定、速度上不去这些问题困扰，这篇笔记应该能帮上忙。

1. 基础认知：SD卡在ARM系统里的定位与核心概念

在深入代码之前，先把SD卡在嵌入式系统里的角色理清楚。这很重要，因为很多问题其实是概念没搞清导致的。

1.1 从物理接口到存储介质：SD卡本质是什么

SD卡全称Secure Digital Memory Card，是一种基于NAND Flash的存储设备。它在ARM系统里扮演的角色是外部非易失性存储器，用来存放需要掉电保存的数据：日志文件、配置文件、采集到的传感器数据、固件升级包等。相比芯片内部Flash，SD卡容量大（从几十MB到上百GB都有）、可插拔、成本低，而且可以方便地把数据拿到PC上分析，所以成了嵌入式设备的标配外设。

从硬件架构上看，SD卡内部其实是一个小型的嵌入式系统——它自己也有控制器，负责管理Flash的读写擦除、坏块管理、磨损均衡、ECC校验这些脏活累活。ARM处理器并不直接操作Flash的物理地址，而是通过SD协议向卡内的控制器发命令。打个比方，ARM像是个甲方，把“我要读地址0x12345678处的数据”这个需求发给SD卡，SD卡内部的控制器接到需求后，再去指挥Flash干活，然后把结果返回给甲方。这个“甲方乙方”的关系理解了，后面看命令交互就好懂了。

1.2 三种操作模式：SD、SPI与SDIO

ARM处理器和SD卡通信，主要有三种方式：

SD模式（也叫SD总线模式）：使用CLK、CMD、DAT0-DAT3共6根线，支持1位或4位并行传输。4位模式下理论吞吐率最高，是性能首选。STM32的SDIO接口跑的就是这个模式。
SPI模式：用CS、CLK、MOSI、MISO四根线，实现简单，很多不带SDIO外设的芯片（比如某些低端MCU）通过GPIO模拟SPI也能驱动SD卡。代价是吞吐率低、没有硬件CRC校验保障，适合对速度要求不高的场景。
SDIO模式：严格说SDIO是MMC/SD规范中定义的一种总线接口标准，在ARM芯片里作为外设控制器存在，通过它操作SD卡就是SD模式。

实际做项目时，如果芯片自带SDIO外设（STM32F1系列、F4系列、H7系列基本都有），优先用SD模式；如果芯片没有SDIO外设，或者引脚被占用太多，就退而求其次用SPI模式。我早年做过一个低功耗采集节点，主控是入门级Cortex-M0芯片，没有SDIO控制器，就是用SPI模式驱动的SD卡，虽然写速度只有几百KB/s，但存定期上传的温湿度数据绰绰有余。

1.3 SD卡规范演进：SDSC、SDHC、SDXC的区别

整个SD家族按容量和规范版本分了三代，对驱动编写有直接影响：

类型	全称	容量范围	文件系统	地址单位
SDSC	Standard Capacity	最大2GB	FAT12/FAT16	字节地址
SDHC	High Capacity	2GB - 32GB	FAT32	块地址（512B/块）
SDXC	eXtended Capacity	32GB - 2TB	exFAT	块地址（512B/块）

关键点在这里：SDSC用字节地址，SDHC/SDXC用块地址（每块512字节），也就是说访问SDHC时，命令参数里的地址是“扇区号”，不是“字节偏移量”。很多新手第一次调SDHC卡，在CMD24写单块命令里填的实际字节地址，结果卡半天没反应，就是这个原因。

还有一个隐藏知识点：CMD8命令就是用来区分SDSC和SDHC的。初始化流程里发CMD8，如果卡响应了0x1AA（表示支持2.7V-3.6V电压范围，且支持SDHC/SDXC），那才能继续发ACMD41带HCS位来切换到高容量模式。不支持CMD8的老卡，只能按SDSC处理。这个细节后面初始化的章节还会展开。

2. SD总线协议核心：命令、响应与数据传输

SD协议本质上是一个命令-响应的主从式协议。ARM作为主机，SD卡作为从机，主机发命令，从机回响应，然后根据命令类型决定是否传输数据。先把这三要素搞明白，驱动逻辑就是顺水推舟的事。

2.1 命令格式：48位的约定

SD总线上传输的每一条命令都是48位，固定格式如下：

起始位（1位）：固定为0
传输位（1位）：固定为1，表示方向是主机到卡
命令索引（6位）：CMD0到CMD63
参数（32位）：具体含义因命令而异，可能是地址、电压范围、块数量等
CRC7（7位）：校验除起始位和传输位外的45位
结束位（1位）：固定为1

CRC7是硬件自动生成的，在SDIO外设里由硬件电路负责，不需要软件去算。但在SPI模式下，CRC7是强制要求为合法值的（SDIO模式对某些命令不检查CRC），所以用SPI模式时，CRC计算往往要软件实现，或者直接参考官方SD卡初始化代码里的查表算法。

2.2 常用命令速查表

驱动编写中最常用的命令就这么几个，建议背下来：

命令	索引	参数	响应类型	用途
CMD0	0	0x00000000	R1	复位卡，进入空闲态
CMD8	8	0x000001AA	R7	发送电压范围查询，检测卡类型
CMD55	55	0x00000000	R1	前缀命令，通知下一条是应用命令
ACMD41	41	0x40000000	R1	初始化卡，HCS位置1开启高容量
CMD2	2	0x00000000	R2	读取卡CID寄存器
CMD3	3	0x00000000	R6	读取卡相对地址RCA
CMD7	7	RCA<<16	R1	选中/取消选中卡
CMD17	17	扇区号	R1	读取单块数据
CMD18	18	起始扇区号	R1	连续读取多块
CMD24	24	扇区号	R1	写入单块数据
CMD25	25	起始扇区号	R1	连续写入多块
CMD12	12	0x00000000	R1b	停止多块传输
CMD13	13	RCA<<16	R2	读卡状态寄存器

2.3 响应类型：读懂卡在说什么

SD卡会返回多种响应，不同命令对应不同响应类型：

R1：常规响应，长度48位，包含卡当前状态。每一位代表一个错误标志，比如参数错误、地址错误、CRC错误、擦除失败等。初始化过程里最常打交道的响应。
R2：CID或CSD寄存器内容，136位，比普通响应长，由发送命令的设备和卡共同组成。读取卡容量、制造商信息就靠它。
R3：OCR寄存器内容，48位，在ACMD41初始化时返回，反映卡电压范围和初始化是否完成。最高位（bit31）为1表示卡上电完成，可以开始寻卡了。
R6：RCA响应，48位，在CMD3之后返回，包含卡的相对地址。
R7：CMD8专用响应，48位，回显主机发的电压范围和检查模式。如果低12位等于0x1AA，说明卡支持SDHC。

这些响应里，R1最常用也最容易忽略细节。比如初始化时发CMD55后再发ACMD41，如果R1的bit0是1，说明卡还在初始化中（busy），需要继续轮询；如果bit0是0，说明初始化完成。判断逻辑对了，才不会陷入死循环。

2.4 数据传输：块是基本单位

在SD模式下，数据传输以块（block）为单位，每块固定512字节（也可以在CSD里查询，但实际通用卡就是512）。读数据时，卡准备好后会在DAT线上一帧一帧地往外发：起始位、数据、CRC16、结束位。写数据时，主机除了发数据和CRC16，还要在卡侧等待忙信号（DAT0拉低表示卡忙于写Flash，主机必须等它拉高才能继续）。

多块读写的性能优势非常明显。单块读的命令开销是固定的（命令+响应+传输时间），但连续读的时候，卡内部可以预读（prefetch），把连续的数据提前搬到缓冲区，流水线作业。实测下来，连续读16块以上，吞吐率能比单块读提升好几倍。

3. ARM平台SD卡驱动：从初始化到读写全流程

理论聊完了，进入实操环节。以STM32的SDIO外设为例，梳理一遍完整的驱动流程。这一步是硬骨头，也是绝大多数问题的藏身之地。

3.1 初始化流程：一步步来，别跳步

初始化是SD卡驱动里最容易出错的地方，因为命令顺序和时序有严格要求。我习惯把初始化分成四个阶段：

阶段一：卡识别

主机发送CMD0，复位卡。条件：时钟频率要低（一般100kHz-400kHz），因为卡上电初期工作频率低，扛不住高速时钟。这步在SDIO外设里要先把CLK配成低速，初始化完成后再提频。
发送CMD8，参数0x1AA，读取R7响应。判断卡是否支持SDHC/SDXC。响应里的电压回显必须是0x1AA才算正常。如果卡无响应或回显异常，多半是卡太老或者接触不良。
循环发送CMD55 + ACMD41（带HCS位），直到ACMD41响应的bit0变为0。注意每次CMD55和ACMD41之间不要插入其他命令。SDR21等高速卡可能在这个循环里轮询几十次才完成，代码里要设置超时，防止卡彻底挂了导致死循环。
读OCR确认电压匹配后，发送CMD2读取CID，再发CMD3获取RCA。CMD3返回的RCA要保存好，后面的CMD7、CMD13都要用到。

阶段二：卡选中

发送CMD7，参数是RCA左移16位，选中这张卡。只有选中状态下的卡才能接收数据读写命令。

阶段三：读写配置

这一步是新手最容易漏的。很多卡在初始化完成后默认是按单数据线、低时钟跑的，如果你直接上4位模式或者高频时钟，写入数据就会出错。所以要做两件事：

传输宽度：发送CMD6（SWITCH命令）或者用ACMD6（SET_BUS_WIDTH），把数据线从默认的1位切换到4位。STM32的HAL库里有SDIO_SetWideBusMode接口，底层就是发ACMD6。
时钟提速：先读CSD寄存器（CMD9），拿到卡的传输速度等级（TRAN_SPEED、CCC等字段），然后判断能不能跑高时钟。比如卡标称Class 10，那50MHz基本没问题；如果是老Class 2的卡，还是老实跑25MHz甚至更低。时钟提频的顺序应该在切换到4位模式之后，不然1位模式下带宽有限，高频也发挥不出来。

阶段四：块大小确认

读CSD或SCR寄存器确认块大小等于512字节，这是唯一在实操中被所有消费级SD卡支持的块大小（工业级特制卡另说）。

到这里，SDIO和卡之间的链路就建立起来了，可以开始真正的数据读写。

3.2 单块读写代码示例

用STM32的标准外设库写一个单块读的示例片段（其他平台逻辑同理）：

uint8_t SD_ReadSingleBlock(uint32_t sector, uint8_t *buf) { SDIO_DataInitTypeDef data = {0}; uint32_t timeout = SDIO_TIMEOUT; // 1. 发送CMD17 SDIO_SendCommand(SDIO_CMD17, sector, SDIO_RESP1); if (SDIO_GetCommandResponse() != SDIO_RESP1) { return SD_ERROR_CMD_RESP; } // 2. 配置接收数据通道 data.DataPath = SDIO_DATAPATH_RECEIVE; data.DataLength = 512; data.DataBlockSize = SDIO_DATABLOCK_SIZE_512B; data.TransferDir = SDIO_TRANSFER_DIR_TO_SDIO; data.TransferMode = SDIO_TRANSFER_MODE_BLOCK; SDIO_ConfigData(&data); // 3. 等待数据接收完成 while (timeout--) { if (SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) { // 读取FIFO中的数据 for (int i = 0; i < 128; i++) { // 512字节 / 4字节 = 128次 ((uint32_t *)buf)[i] = SDIO_ReadFIFO(); } return SD_OK; } } return SD_ERROR_TIMEOUT; }

注意几个细节：

CMD17的参数是扇区号，不是字节地址。写SDHC卡时，直接传逻辑扇区号就行；SDSC卡则要换算成字节地址（扇区号 * 512）。
读取FIFO时按4字节一次读，因为SDIO外设的FIFO是32位宽。如果你的缓冲区地址不是4字节对齐，就会出现HardFault。所以驱动入口处最好做一次地址对齐检查，或者要求调用方必须传入对齐的缓冲区。
超时时间不能设太短。SD卡在写Flash时会发生“写放大”现象，实际写入时间可能比理论时间长一个数量级。我遇到过一张老卡，写单块偶尔要20ms才返回，超时设短了就会出现写失败。

3.3 多块读写：性能来源

多块读写主要用在高吞吐场景：录音设备写音频流、数据采集器周期性存批量数据、OTA升级包写入等。SD模式下，多块读是连续地址的，命令只需要一次（CMD18）发出去，后续数据块按流水线持续传输，直到主机发CMD12停止。

写多块时有一个坑：预擦除。很多卡在多块写前需要发ACMD23（SET_WR_BLK_ERASE_COUNT），告诉卡接下来要写多少块，卡可以提前做Flash预擦除，减少时间损耗。如果跳过ACMD23，多块写的总耗时可能翻倍。我还遇到过某些卡不先擦除就直接连写，写到一半返回数据错误，加上ACMD23就一切正常。

我在项目中测试过一张Class 10的32GB卡，单块写（CMD24）吞吐率大概1.5MB/s，多块写（CMD25 + ACMD23，一次写64块）能到4MB/s以上。读的差距更大，单块读1.8MB/s，多块读能接近8MB/s。如果你的应用是持续大量写日志，多块写是必须的。

3.4 中断和DMA：别让CPU被FIFO拖死

数据接收时，如果纯粹用轮询方式读FIFO，CPU会被OTL的时钟频率绑在循环里——每来4字节就打断一次，主控干不了别的。这在实时性要求高的系统里是灾难。所以主流做法是：

DMA方式：配置DMA自动把SDIO接收FIFO的数据搬运到内存缓冲区，传输完成后触发DMA中断。CPU在DMA搬运期间可以处理其他中断任务。
中断方式：配置SDIO接收FIFO半满/全满中断，在中断里搬数据。比DMA轻量，但中断频率高，适合DMA通道不够用的小资源芯片。

ST的HAL库提供了SDIO_DMA传输的封装，但有个暗坑：FIFO的DMA突发模式配置、DMA请求和SDIO中断之间的竞争。我曾经遇到DMA传输完成的标志时刻晚于实际数据写完，导致主程序去访问还没更新的缓冲区，数据不对。解决方案是开启DMA的传输完成中断，同时禁用FIFO interrupt，让DMA中断作为唯一完成信号。

4. 文件系统层面：FatFs的引入与适配

驱动层面搞定SD卡读写，应用层还需要文件系统。嵌入式世界最流行的就是FatFs，它开源的、可裁剪的、支持FAT12/16/32和exFAT，代码量小，移植也不难。

4.1 标准挂载流程

FatFs的移植核心是提供底层接口函数，通常要写6个：

disk_status：返回磁盘状态
disk_initialize：初始化SD卡（调用SD读写驱动）
disk_read：读扇区（可多扇区）
disk_write：写扇区（可多扇区）
disk_ioctl：控制命令，如获取扇区数、扇区大小、擦除块数量
get_fattime：返回当前时间，用于文件时间戳

代码骨架如下：

DRESULT disk_read(BYTE pdrv, BYTE *buff, LBA_t sector, UINT count) { if (pdrv != 0) return RES_PARERR; // 多块读，连续读效率更高 if (count == 1) { SD_ReadSingleBlock(sector, buff); } else { SD_ReadMultiBlocks(sector, buff, count); } return RES_OK; } DRESULT disk_write(BYTE pdrv, const BYTE *buff, LBA_t sector, UINT count) { if (pdrv != 0) return RES_PARERR; if (count == 1) { SD_WriteSingleBlock(sector, (uint8_t *)buff); } else { SD_WriteMultiBlocks(sector, (uint8_t *)buff, count); } return RES_OK; }

单块/多块分派逻辑必须做。FatFs底层碎片化严重的时候会落成很多单扇区写，这时候如果驱动直接把单扇区也当作多块来发，会产生错误。

4.2 FatFs配置要点

ffconf.h里有几个关键配置项，按项目需求设置：

_FS_READONLY：只读文件系统设为1可省RAM和Flash，但很多写日志的应用不能设为1。
_USE_MKFS：需要在设备上格式化SD卡（通过f_mkfs函数）时设为1。
_USE_LFN：支持长文件名。FAT格式里长文件名需要占用额外的扇区缓冲，_USE_LFN设为2（用堆分配）能省一点静态内存，但要注意malloc可用性。
_MAX_SS：扇区大小最大值，FATFS默认512就够了。如果你的卡支持4096字节扇区（高级格式卡），要设为4096。
_FS_EXFAT：需要支持exFAT时开启。不过老一点的STM32工程RAM紧张，exFAT缓冲区要求挺高，8KB打底，评估后再开。

体积方面，全功能配置下FatFs大概占6-10KB Flash，1KB左右的RAM（不含文件缓冲），在F103这种256KB Flash的平台上毫无压力。

4.3 格式化与挂载初始化示例

设备首次上电处理SD卡时，我用下面的逻辑：

FRESULT init_sd_fat(void) { FATFS fs; FRESULT res = f_mount(&fs, "0:", 1); // 立即挂载 if (res == FR_NO_FILESYSTEM) { // 没有文件系统，尝试格式化 res = f_mkfs("0:", NULL, 0, 0); if (res != FR_OK) return res; res = f_mount(NULL, "0:", 0); res = f_mount(&fs, "0:", 1); } return res; }

f_mkfs格式化时间不短，大卡可能要几秒到几十秒（视卡速而定）。格式化进行中千万不能掉电，否则文件系统半载状态是最难恢复的。建议在产品说明里写明“首次使用请保持供电，等待初始化完成”。

另外，f_mount的第三个参数设为1会立即挂载，如果卡没插或初始化失败，返回的错误码要捕捉到，并做好UI提示或系统状态位。

5. 实操中我踩过的坑与通用排查思路

最后这部分是最值钱的。SD卡在嵌入式里出问题，很多不是大方向错了，而是细节翻车。我把这些年收集到的经典问题和排查思路整理成清单，按概率排序。

5.1 卡初始化失败，卡被系统识别不到

这是出场率最高的问题。排查路径按顺序走：

先查硬件接线：是否共地，上拉电阻是否接好（SD卡的CMD、DAT0-3、CLK都需要10k-100k上拉，部分开发板已经自带上拉，外接注意别重复）。用示波器看CLK引脚是否有正常方波输出，如果没有，先修硬件。
查上电时序：确认卡插入后是否先给卡供电稳定（至少要等几个ms的VDD建立时间）再发CMD0。我见过有些板子卡座有热插拔供电切换电路，上电瞬间电压爬坡不稳，导致卡初始化失败。解决的方法是SD卡电源引脚加个大电容（100uF级别），并在代码里启动后延时50ms再初始化。
查初始化时钟频率：确认初始化阶段时钟是否低于400kHz。有的片子改动时钟树时把SDIO CLK直接配成48MHz去发CMD0，这时初始化必失败。初始化阶段降频是很多老工程师的习惯，不要跳。
CMD8响应异常：R7响应的低12位不是0x1AA，或者卡完全无响应。大概率是卡不是标准卡（比如山寨扩容卡、某些工业卡对CMD8有特殊处理），这时候只能按SDSC流程跑，发CMD55/ACMD41时不要置HCS位。

5.2 写入数据后读出来校验失败

问题表现为：写文件后读文件，内容不完整、乱码、开头数据对但后面全错。

原因排查顺序：

缓冲区未对齐：DMA访问内存需要4字节对齐。如果应用层传入的buf地址是奇地址（比如结构体里的字段），DMA写入就会错乱。我在项目里要求FatFs配置_USE_LFN=2同时给文件缓冲的堆内存16字节对齐，解决过好几次随机写坏的问题。
DMA缓冲区正在被访问：DMA搬运前主机已经把数据写到buf，但DMA还在搬运时主机又改了buf内容，最终DMA搬了一半旧数据、一半新数据。解决方法是DMA写完后等中断标志位，再让主机改buf；或者使用双缓冲区轮转，交替更新。
时钟过高超出卡能力：卡标称Class 10不代表在任何条件下都能跑满50MHz。如果遇到整块数据校验异常，先把时钟降到25MHz试试。我在一块PDD上买的所谓“高速卡”上遇到过必须降到12.5MHz才能稳定的情况。

5.3 文件系统挂载慢或者挂载失败

有时候卡能读写，也格式化成FAT32了，但挂载时间奇长（几秒钟），甚至挂不上。

主要原因：卡的数量多、坏块多、文件系统碎片严重。FatFs挂载时要扫描FAT表，FAT32的FAT表占空间很大（1GB的卡至少1MB FAT表），如果底层驱动每读一个扇区都要额外附加延迟，挂载自然慢。改善方法：

底层多块读直接传给驱动，FatFs内部本来也是按簇读写，连续簇的读取是连续扇区，接得住。
定期维护文件系统，比如每周格式化一次，避免长期增删文件导致碎片膨胀。
对要求高可靠性的场景，预留一个固定大小的预分配文件（比如日志文件创建时直接设置大小），减少运行时动态分配文件的碎片。

5.4 热拔插损坏文件系统

嵌入式设备如果允许用户带电拔卡，那文件系统损坏是迟早的事。硬件上一定要加卡检测开关：

卡座通常带CD（Card Detect）引脚，接一个GPIO，检测卡在位状态。
软件上轮询CD引脚（比如每100ms读取一次），检测到卡拔出时立即f_mount(NULL, "0:", 0)卸载文件系统，之后所有文件操作返回错误。
重要数据（比如系统配置文件）在写入时做“文件写完-落盘”两步走（f_sync函数），保证在拔卡瞬间最近的写操作已经同步到磁盘。

我项目里用的策略是：检测到拔卡事件后，不立即执行卸载，而是标记“卡即将移除”，当前文件写入加锁，下一次写操作前再真正卸载，避免在中断上下文做重操作。

5.5 大容量卡（64GB/128GB）格式化问题

有些项目要用大容量卡存长时间数据。FAT32格式在Windows下默认支持到32GB，64GB以上在PC上格式化时默认选exFAT。但很多嵌入式芯片和FatFs配置并没有开启exFAT支持，这时如果你直接把一张128GB的exFAT卡插进设备，系统会显示“无文件系统”。

解决思路：

开启FatFs的exFAT支持（_FS_EXFAT设为1），并在disk_ioctl里正确返回扇区大小。
或者用PC把卡重新格式化成FAT32（第三方工具如大容量格式化工具），但FAT32在128GB上性能一般，而且Windows 原生工具限制在32GB。
还有一种做法：分区表+多分区。嵌入式上把卡分成两个FAT32分区，32GB存普通文件，剩余存大文件流水数据。只是复杂度上去了，一般不建议。

5.6 速度达不到预期，卡慢得像蜗牛

写性能差的现象是：写入文件时平均速率很低，或者间歇性卡顿。诊断方向：

确认是否真的用了多块写。单块写每512字节就要一次完整命令-响应-忙流程，效率极低。
确认是否发了ACMD23预擦除。对某些卡来说这步能省一大半时间。
检查是否有“写同步”拖后腿。FatFs的f_sync调用，每次都会强制卡把缓存中的内容落盘到Flash，太频繁地sync（比如每写10字节就sync）会让性能暴跌。合理的做法是：每写一批数据（比如4KB-32KB）才sync一次，或者关闭f_sync，依赖卡自身的缓存管理。

5.7 不同批次卡兼容性差异

这是最让人头疼的。同一个工程，A厂家的卡跑得好好的，换成B厂家的卡就初始化失败或者写坏块。

解决办法没有银弹，核心思路是“降级兼容”：

初始化时序严格按规范来，不依赖厂商扩展命令。
时钟不要一上来就跑满高速，启动阶段400kHz，初始化后先跑25MHz，确认读写正常再提速。可以在板级配置里预留一个“兼容模式”宏，调试时切换。
单块读写失败时，驱动层做3次重试（SD协议是允许重try的），重试前重新配置数据通道和FIFO。
对工业产品，建议做一张经过测试的兼容卡列表（比如只认证三家卡厂），写在用户手册里，避免用户随便插卡导致售后问题。

6. 稳定性设计：一个可靠的SD卡子系统怎么搭

光把SD卡跑通还不够，嵌入式产品要的是“长期稳定运行”。我分享几个我认为比较重要的设计习惯。

6.1 超时机制与错误恢复

SD卡命令都要有超时，不能让代码无限等待。我一般在驱动层定义一个函数：

uint8_t SD_WaitResponse(uint8_t expected, uint32_t timeout_ms) { uint32_t tick = 0; uint32_t start = HAL_GetTick(); while (HAL_GetTick() - start < timeout_ms) { if (SDIO_GetFlagStatus(...) == expected) return OK; } return TIMEOUT; }

超时后的恢复流程也很重要。卡超时可能是瞬时错误（总线抖动），也可能是永久错误（卡损坏）。我习惯先做一次卡复位（CMD0），如果复位后初始化成功就继续用；如果复位后还是失败，才认定卡失效。

6.2 掉电保护与日志可靠性

嵌入式设备最容易出问题的场景是：写文件到一半系统断电，然后文件系统损坏。

除了硬件上增加掉电检测外，软件层有不少能做的：

日志文件按天创建，一天一个，坏了只坏一天的日志，不影响历史数据。
关键配置文件（比如系统参数）写入时采用“双份冗余”：写A区，校验通过后再写B区，读取时优先读A区，A区校验失败则回退B区。这样即使某次写入被掉电打断，至少有一份是完整的。
写入文件后用f_truncate和f_sync组合，确保文件大小字段先更新再更新数据，可以减少FAT表损坏的概率。

6.3 坏块的软件层辅助

SD卡自身会管理坏块，但主控层也可以做一些辅助。一个实用的做法是：以“扇区写成功后记录”的方式维护坏扇区表。日常写入时如果某扇区返回错误，标记备用；重试一次不成再标记。这样连续多次错误时，可以立即切换到另一张新卡或者降低工作模式，不至于突然把整个文件系统干废。

不过要注意，别自己做低层坏块管理。SD卡内部的控制器已经做过了，主控再做反而会冲突。主控层面的“坏扇区表”只是标记不可用的逻辑扇区，避免反复写入，仅此而已。

6.4 性能预算与缓冲区规划

SD卡子系统对MCU资源的消耗不小，尤其是DMA缓冲区和FatFs的工作区。我一般把SD卡缓冲区单独划一块RAM，用__attribute__((aligned(4)))或者链接脚本放到对齐地址。DMA的缓冲改成double buffer后，内存翻倍（我项目里是用8KB双缓冲），Flash剩个几十KB时要注意。

缓冲区规划的经验值：如果只做写入，读缓冲4KB、写缓冲4KB就够用；如果还要做文件浏览、读取音频流，读缓冲16KB以上，写缓冲4KB以上，配合二级缓存效果更好。

7. 实测记录：一张普通Class 10卡的读写性能

纸上谈兵没意思，放一组我在项目板（STM32F407 @ 168MHz，SDIO 4位模式，50MHz时钟）上的实测数据，供参考。

操作	块大小	命令组合	实测吞吐率
单块读	512B	CMD17	1.5 MB/s
多块读 (64块)	32KB	CMD18	8.1 MB/s
单块写	512B	CMD24	1.4 MB/s
多块写 (64块)	32KB	CMD25 + ACMD23	4.2 MB/s
多块写 (128块)	64KB	CMD25 + ACMD23	4.5 MB/s

读明显比写快，这是NAND Flash的特性——写入需要擦除、纠错，耗时远高于读。另外可以看到，块大小从32KB加到64KB，写速度提升有限，说明瓶颈已经不在块调度，而在Flash本身了。

我还在另一张杂牌Class 4卡上做过测试，多块写只能跑2.3MB/s，而且单块写时经常需要重试。所以产品级设计时，SD卡驱动最好带一个“性能自检”功能：初始化后用固定的时间窗口测一遍实际吞吐，如果低于阈值（比如2MB/s），可以提示用户换卡。

7.1 速度上不去的下一步优化方向

如果你对性能还有更高的追求，可以考虑：

提高SDIO时钟：H7系列能跑SDIO 100MHz+，但卡是否支持得看卡的标准。Class 10卡一般在50MHz内稳妥。
准备多个活跃缓冲区：多缓冲轮转，在DMA搬运当前数据块时，CPU提前准备下一块数据，隐藏排队时间。
数据调度：把多个小文件写请求合并成一个大块连续写，减少命令开销。
关闭FatFs的FIFO缓冲：如果系统RAM紧张，FIFO缓冲其实可以关闭，每次读写直接搬数据，但性能会打折。

SD卡这块学到一定程度，你会发现它其实是个很好的“模版型外设”——掌握了它的命令-响应机制，再去玩NAND Flash、eMMC、甚至NVMe，思路都是相通的，只是总线宽度、协议复杂度、命令集不一样。这也是为什么几乎所有的ARM嵌入式教程都会把SD卡当作一个必讲模块的原因。

就我自己这几年的经验来说，SD卡驱动和文件系统移植，真正难的不是看懂协议，而是把协议落到具体的硬件外设上，还要考虑各种卡、各种环境、各种意外情况下的鲁棒性。你现在看到的所有“坑”，其实都是好老师。如果你正在调SD卡相关代码，卡在某个初始化步骤过不去，或者连续写入总是偶尔出错，把上面说的排查路径从头走一遍，八成能找到原因。耐心一点，SD卡的脾性摸透了，后面用起来会顺手很多。

ARM嵌入式SD卡驱动实战：从协议机制到文件系统移植