2026/9/6 3:23:07
FEATURED · 精选文章 
搞嵌入式的人迟早会遇到这么一档子事程序里要存几张图片、一组字库、或者跑一段长时间的运行日志板子上的Flash不够用了外挂SD卡又觉得“杀鸡用牛刀”毕竟卡座要占PCB面积、要买卡、还要考虑接触可靠性。我最早是硬着头皮用SPI Flash一颗一颗往上堆容量后来发现一颗国产的MK SD NAND就能把问题解决得挺干净而且驱动起来并不比Flash复杂多少。这次就用正点原子STM32精英板把整个跑通过程拆成三步给大家做个参考。说的MK SD NAND其实就是把NAND Flash颗粒和SD控制器封装在一颗芯片里对外直接提供SD协议接口。你不用管坏块管理、擦写均衡、ECC校验这些底层破事把它当成一张贴片式的SD卡就行。这对于习惯裸机开发、又不想为Flash写复杂FTL算法的团队来说非常省心。正点原子精英板上的主控是STM32F103ZET6板载资源里有SDIO接口和SPI接口搭配MK SD NAND跑FatFs文件系统在标准库和HAL库环境下都能比较轻松地实现。这篇文章适合谁看呢正好在用正点原子精英板、或者手头有类似STM32F1/F4系列板子的人想给项目加一个容量可观128MB到数GB、还不用占太大面积的存储方案同时对只跑过W25Q系列的SPI Flash、没碰过SD协议的人也很友好。下面按我的实操顺序从选型认知讲到底层驱动再到文件系统挂载一步步说清楚。1. MK SD NAND到底解决了什么问题1.1 一颗芯片替代一张卡槽的思维转变很多人第一次听到SD NAND第一反应是“这不就是个没有外壳的SD卡吗”。话糙理不糙但这里面的门道远不止“省掉外壳”这么简单。SD NAND在封装形式上直接做成LGA-8贴片封装能用SMT贴片机直接打在PCB上不需要卡座、不需要买TF卡、不需要考虑用户插拔方向。这对于量产产品来说整个BOM和生产环节都省了不少事。更重要的是可靠性和一致性。独立的SD卡是消费品卡的质量参差不齐跑一段时间出现坏块、掉速甚至数据丢失是常有的事。而SD NAND出厂前经过了筛选和初始化控制器内置了坏块管理和磨损均衡对主控芯片来说它就是一个标准SD设备不需要你额外写Flash管理算法。以MK系列常见的容量为例单颗就能做到128MB到数GB冗余度要比常见板载Flash大得多。另外一个小优势很多人可能没意识到它占用的是标准SD协议也就意味着主控端无论是用SDIO、还是用SPI都能访问。这对于引脚紧张的板子非常友好。F103ZET6虽然不缺引脚但如果你用的是小封装的F103C8T6之类的芯片SPI模式接四根线就能获得一个几百MB的存储空间性价比极高。1.2 MK SD NAND与SD卡、SPI Flash的核心差异这三个东西放在一起对比能帮你快速判断什么场景该选谁对比维度MK SD NANDTF卡 卡座板载SPI Flash封装形式LGA-8贴片适合量产插拔式适合开发调试SOP-8等贴片封装接口协议SDIO / SPISDIO / SPISPI容量上限数百MB至数GB数GB至数十GB通常8MB~64MB坏块管理内置控制器处理由卡内部处理需要自研或依赖库磨损均衡内置依卡品质而定需要自研占用PCB面积极小较大含卡座小BOM成本中等低但卡品质不可控低从表格能看出来SPI Flash的唯一优势是价格便宜、电路简单但容量一大成本反而会比SD NAND更高而且代码复杂度陡增。TF卡的优势是灵活、替换方便可它最大的软肋是插拔接触和品质一致性。生产过产品的人都有体会卡座带来的售后问题远比你想象得多。1.3 它适合跑在什么场景里结合我自己的项目经验以下几个场景用MK SD NAND特别合适存储GUI图片资源、字库文件。比如用LVGL做界面图片资源动辄几MB到几十MB放SD NAND里按需从文件系统读取既节省Flash又不占用RAM。长时间数据采集与日志记录。传感器数据、GPS轨迹、故障日志配上FatFs按天建文件存储上完全不用操心容量。音频播放。比如语音提示、短音频回放数据量在几十MB级别SD NAND的连续读速度比SPI Flash快得多。轻量级文件交换。设备配置参数、升级固件包直接在电脑上将文件通过读卡器写进SD NAND设备上电就能解析。这一点在实际产线上很有用比用专用烧录器方便。2. 精英板上的SPI接线与SDIO方案取舍2.1 为什么我最终选了SPI模式而不是SDIO精英板板载的SD卡座默认用的是SDIO 4-bit模式而SDIO接口在F103上需要复用PB8~PB11等引脚同时要额外准备一个DMA通道来搬运数据底层代码量明显上了一个台阶。如果你的核心诉求是“快速跑通”和“理解协议”SPI模式是最直接的选择。SPI模式有几个不可替代的好处引脚占用少只要SCK、MISO、MOSI、CS四根线外加电源和地一共六根线就能跑。代码复用度高正点原子例程里面的SPI Flash驱动框架可以直接改造成SD卡驱动底层就换个命令集合而已。调试方便SPI时序可以用逻辑分析仪直接抓出问题时定位比SDIO快得多。当然SPI模式读取速度确实不及SDIO理论上SPI时钟跑到18MHz时读速度大约能到1~2MB/s写速度更慢一些。对于只存图片、字库、日志这类对实时性要求不高的场景这个速度完全够用。真要做高速音视频流再考虑上SDIO 4-bit模式不迟。2.2 引脚对应关系与接线图正点原子精英板上引出的SPI2接口在板子背面或者右侧排针处能查到对应的引脚关系如下MK SD NAND引脚功能精英板引脚说明CS片选PB12SPI2_NSS软件控制SCK时钟PB13SPI2_SCKMISO主入从出PB14SPI2_MISOMOSI主出从入PB15SPI2_MOSIVCC电源3.3V典型供电3.3V注意别接5VGND地GND共地接线时有两个必须注意的地方千万不要把VCC接到5V上。虽然有些SD卡模块带电平转换支持5V供电但SD NAND芯片本身是纯粹的3.3V器件接了5V轻则工作不稳定重则直接烧掉。CS引脚建议用普通GPIO控制不要用SPI外设的硬件NSS。原因是硬件NSS在通讯异常时可能被拉低导致SD卡误进入SPI模式增加排查难度。软件控制CS最省心读写前拉低结束后拉高。2.3 精英板上跑SPI需要额外注意的电平细节STM32F103的GPIO是5V容忍的但SD NAND不是。虽然SPI是3.3V逻辑电平与F103的IO电平匹配没有问题但在调试时有些细节容易被忽略。比如上电顺序。如果先给STM32供电再给SD NAND模块供电可能出现IO口高电平灌入未上电芯片的情况。实际接线上只要VCC用同一个3.3V来源上电顺序问题基本可以忽略但如果你用的是外部独立供电模块最好在MCU初始化SPI引脚时先把它们设为浮空输入等确认供电稳定后再配置为复用推挽输出。另一个容易被忽略的点是SD卡协议要求SPI模式下SCK的默认状态是低电平CPOL0数据在第一个时钟沿采样CPHA1也就是SPI模式3。这个在后面配置寄存器时会用到千万别配成模式0或者模式2否则命令发出去基本石沉大海。提示正点原子精英板的板载SD卡座和SPI Flash复用了一部分引脚如果你同时插了SD卡又外挂了SD NAND模块可能产生总线冲突。做实验时优先确保只有一个设备挂在同一条SPI总线上。3. SPI驱动改造从Flash例程到SD卡命令集的迁移3.1 SD卡在SPI模式下的初始化流程SD卡的初始化流程和SPI Flash完全不同这也是从Flash转过来的人最容易卡住的地方。简单来说SD卡上电后首先进入的是SD模式必须发送特定序列的命令把它切换到SPI模式然后才能进行后续的容量读取和读写操作。整个初始化过程可以拆成以下几个步骤上电后先给SD卡至少74个时钟周期让它完成内部上电复位。实际操作时可以直接发送80个字节的0xFF来保证时钟数足够。发送CMD00x40同时把CS引脚拉低。SD卡收到CMD0后应答0x01表示进入空闲状态Idle State。发送CMD80x48检查卡是否支持SD V2.0协议。这条命令的响应低32位如果是0x1AA说明卡支持2.0协议是SD NAND最常见的应答。循环发送CMD55ACMD410x77, 0x69, 然后CMD41为0x69组合直到响应变为0x00表示卡退出空闲状态完成初始化。读取OCR寄存器、CSD寄存器确认卡的容量和扇区信息。你可能会问为什么初始化序列这么啰嗦因为SD协议本身要兼容不同厂家、不同代的卡。CMD8负责探测协议版本ACMD41负责协商工作电压范围、使能卡内部上电整个过程就是“握手-确认身份-协商参数”的流程。用生活化的类比这就像两个陌生人要合作得先互报家门确认身份再谈好合作条件最后才能开始干活。3.2 在正点原子SPI Flash驱动框架上改造命令函数正点原子标准库例程里的SPI Flash驱动底层有SPI_Flash_ReadByte()和SPI_Flash_SendByte()这两个函数这是整个驱动的基础。SD卡驱动也一样只不过SD卡需要额外的CS控制和命令响应处理。下面是SD卡SPI驱动中几个核心函数的代码实现可以直接替换掉原来Flash驱动里的对应逻辑// 发送一个命令给SD卡cmd为命令索引arg为参数crc为CRC校验 u8 SD_SendCmd(u8 cmd, u32 arg, u8 crc) { u8 r1; // 片选拉低开始传输 SD_CS_LOW(); // 发送起始位和命令索引格式为01xxxxxx SPI_Flash_SendByte(cmd | 0x40); // 发送参数大端序 SPI_Flash_SendByte(arg 24); SPI_Flash_SendByte(arg 16); SPI_Flash_SendByte(arg 8); SPI_Flash_SendByte(arg); // 发送CRCCMD0和CMD8这些特殊命令需要有效CRC其余可发送0xFF SPI_Flash_SendByte(crc); } // 接收SD卡返回的R1响应 u8 SD_GetResponse(u8 Response) { u16 i 0; // 一直读直到收到想要的响应超时退出 while (i 0x0FFF) { u8 r SPI_Flash_ReadByte(); if (r Response) { return 0; // 获取成功 } i; } return 1; // 超时失败 }初始化函数里最关键的是发送CMD0之前要先把SPI时钟降到400kHz以下等卡完成初始化后再提高到最高速率。这一点新手特别容易忽略一上来就用高速时钟发CMD0卡根本不响应。原因在于SD卡协议规定SD卡唤醒和识别阶段必须工作在低速模式下高速率是初始化完成之后才允许的事。我实际调试时踩过这个坑一开始用2MHz的SPI时钟发CMD0连续几天都读不回0x01最后把时钟降到250kHz一发就通了。从那时起我养成了习惯凡是初始化序列一律先低速跑判断完卡类型再切高速。3.3 初始化完整代码参考把上面的命令发送函数串起来就是完整的SD卡初始化流程u8 SD_Init(void) { u8 r1; u16 i; // 初始化SPI2设置低速模式 SPI2_Init(); // 释放CS并发送至少74个时钟周期的0xFF SD_CS_HIGH(); for (i 0; i 10; i) { SPI_Flash_SendByte(0xFF); } // 片选拉低正式进入SPI模式 SD_CS_LOW(); // 发送CMD0进入空闲态 SD_SendCmd(0, 0, 0x95); // CMD0的CRC固定为0x95 r1 SD_GetResponse(0x01); // 期望收到0x01 if (r1 ! 0) return 1; // CMD0失败 // 发送CMD8检查卡类型 SD_SendCmd(8, 0x000001AA, 0x87); // CMD8的CRC固定为0x87 r1 SD_GetResponse(0x01); if (r1 ! 0) return 2; // 不支持SD V2.0 // 读取CMD8的后32位检查是否为0x1AA for (i 0; i 4; i) { u8 tmp SPI_Flash_ReadByte(); if ((i 2) (tmp ! 0x01)) return 3; if ((i 3) (tmp ! 0xAA)) return 4; } // 循环发送ACMD41直到卡就绪 for (i 0; i 200; i) { SD_SendCmd(55, 0, 0x01); // 先发CMD55表示下一条是应用命令 SD_GetResponse(0x01); SD_SendCmd(41, 0x40000000, 0x01); // HCS1表示支持高容量卡 r1 SD_GetResponse(0x00); // 期望收到0x00 if (r1 0) break; // 卡初始化完成 delay_ms(10); // 没就绪就等一会儿再试 } if (i 200) return 5; // 初始化超时 // 读取CSD寄存器获取卡容量信息略后面单独说明 SD_ReadCSD(); // 切换SPI为高速模式 SPI2_SetSpeed(SPI_SPEED_18M); return 0; // 初始化成功 }提示代码里SD_CS_LOW()和SD_CS_HIGH()是软件控制PB12的宏别直接替换成Flash的片选控制。很多人在移植时把片选搞混导致SD卡一直处于选中或非选中状态初始化自然过不去。3.4 读CSD寄存器获取容量信息SD卡的容量信息藏在CSD寄存器里不同版本协议解析方法不一样。SD V2.0的高容量卡CSD版本为1容量计算公式比较简单// 读取CSD寄存器的前16个字节 u8 csd[16]; u8 SD_ReadCSD(void) { u8 i; SD_SendCmd(9, 0, 0x01); // CMD9读取CSD u8 r1 SD_GetResponse(0x00); if (r1 ! 0) return 1; // 等待数据起始令牌0xFE u16 timeout 0; while ((SPI_Flash_ReadByte() ! 0xFE) (timeout 0xFFFF)) timeout; if (timeout 0xFFFF) return 2; // 读取16字节CSD数据 for (i 0; i 16; i) csd[i] SPI_Flash_ReadByte(); // 跳过2字节CRC SPI_Flash_ReadByte(); SPI_Flash_ReadByte(); return 0; } // 解析CSD获取容量单位KB u32 SD_GetCapacityKB(void) { if ((csd[0] 6) 1) { // SD V2.0高容量卡C_SIZE为csd[8]的低2位 csd[9] csd[10]的高6位 u32 c_size ((csd[8] 0x3F) 16) | (csd[9] 8) | csd[10]; return (c_size 1) * 1024; // 单位是KB } else { // 旧版SD卡/标准容量卡解析方式不同 u32 c_size ((csd[6] 0x03) 10) | (csd[7] 2) | ((csd[8] 0xC0) 6); u32 c_size_mult ((csd[9] 0x03) 1) | ((csd[10] 0x80) 7); u32 read_bl_len csd[5] 0x0F; return (u32)((c_size 1) * (1 (c_size_mult 2)) * (1 read_bl_len)) / 1024; } }这里有个小细节CSD寄存器的数据读取过程有一个0xFE数据起始令牌函数里用了超时循环这种超时机制在后面读扇区时也会用到。4. 文件系统接入FatFs在精英板上的移植要点4.1 为什么选择FatFs而不是其他文件系统SD NAND的底层驱动打通了接下来自然要建文件系统。目前STM32界最主流的方案就是FatFs几乎没有之一。它占用资源少原生支持FAT32跟Windows兼容性好在嵌入式领域算得上是事实标准。有人可能问LittleFS不是也很火吗LittleFS的优势在于掉电安全和磨损均衡但它是日志结构的文件系统Windows无法直接识别要配合专用工具才能在电脑上读取里面的文件。而FatFs的好处是你直接把SD NAND在电脑上格式化好再插回板子上程序就能直接读。对于MK SD NAND这种内置了坏块管理和磨损均衡的芯片FatFs的劣势反而没那么明显。芯片在底层已经帮我们做了大量Flash管理文件系统层面只要正常挂载、读写就行经典的FatFs方案是最稳妥、最少坑的选择。4.2 diskio底层接口对接FatFs官方源码包里有五个底层接口需要实现对应到SD卡驱动就是FatFs接口作用SD驱动映射disk_initialize初始化磁盘调用SD_Init()disk_status获取磁盘状态返回STA_NOINIT或0disk_read读取扇区调用SD_ReadDisk()disk_write写入扇区调用SD_WriteDisk()disk_ioctl控制命令实现GET_SECTOR_COUNT等disk_read和disk_write是最核心的两个函数。SD卡在SPI模式下以扇区为单位读写数据每个扇区512字节读写前需要发送命令等待数据令牌然后连续传输512字节最后还有2字节CRC需要接收或发送。读扇区函数的代码实现如下u8 SD_ReadDisk(u8 *buf, u32 sector, u8 cnt) { u8 r1; u16 i; u16 timeout; for (i 0; i cnt; i) { // 发送CMD17读取单扇区 SD_SendCmd(17, sector i, 0x01); r1 SD_GetResponse(0x00); if (r1 ! 0) { return 1; // 命令响应超时 } // 等待数据起始令牌0xFE timeout 0; while ((SPI_Flash_ReadByte() ! 0xFE) (timeout 0xFFFF)) timeout; if (timeout 0xFFFF) return 2; // 等待数据超时 // 读取512字节数据 for (u16 j 0; j 512; j) { buf[i * 512 j] SPI_Flash_ReadByte(); } // 跳过2字节CRC SPI_Flash_ReadByte(); SPI_Flash_ReadByte(); } return 0; }写扇区稍微有点不同需要发送CMD24写单扇区然后先发送数据起始令牌0xFE再连续发送512字节数据最后发送2字节CRCSPI模式下发送0xFF即可然后读取芯片返回的数据响应字节检查是0x05数据接受还是0x0B数据拒绝。4.3 FatFs配置选项的合理设置FatFs源码中的ffconf.h配置文件直接决定了文件系统的大小和功能有几个选项必须根据SD NAND的特性来调整#define FF_USE_MKFS 1 // 允许格式化 #define FF_USE_STRFUNC 1 // 允许文件流函数 #define FF_USE_LFN 2 // 支持长文件名动态内存 #define FF_FS_MINIMUM 0 // 全功能模式 #define FF_FS_RPATH 1 // 支持相对路径其中FF_USE_LFN建议设置为2使用动态内存分配长文件名缓冲区可以显著节省RAM占用。如果工程里RAM吃紧也可以设置为1用静态数组但要注意数组大小要足够大至少256字节。另外一个容易踩坑的配置项是FF_USE_MKFS。如果你希望程序运行时能直接格式化SD NAND比如首次上电发现没有文件系统时自动格式化必须把这个宏设为1并且在disk_ioctl里正确实现GET_SECTOR_COUNT、GET_BLOCK_SIZE这两个命令否则f_mkfs()会失败或直接死循环。4.4 文件读写测试与常见报错排查移植完成后写个简单的测试函数验证一下整条链路是否通畅void FATFS_Test(void) { FATFS fs; FIL file; UINT bw, br; FRESULT res; // 挂载文件系统 res f_mount(fs, 0:, 1); if (res FR_NO_FILESYSTEM) { // 没有文件系统格式化 res f_mkfs(0:, 0, 0); if (res ! FR_OK) { printf(Format failed: %d\r\n, res); return; } res f_mount(fs, 0:, 1); } if (res ! FR_OK) { printf(Mount failed: %d\r\n, res); return; } // 写文件测试 res f_open(file, test.txt, FA_CREATE_ALWAYS | FA_WRITE); if (res FR_OK) { char *data Hello MK SD NAND!\r\n; f_write(file, data, strlen(data), bw); f_close(file); printf(Write %d bytes\r\n, bw); } else { printf(Open failed: %d\r\n, res); } // 读文件测试 res f_open(file, test.txt, FA_READ); if (res FR_OK) { char buf[64] {0}; f_read(file, buf, sizeof(buf) - 1, br); f_close(file); printf(Read %d bytes: %s\r\n, br, buf); } else { printf(Open failed: %d\r\n, res); } // 注销文件系统 f_mount(NULL, 0:, 1); }如果这个测试函数跑下来能正确打印出“Hello MK SD NAND!”这一行恭喜你整条链路已经通了。如果在过程中遇到问题大部分都集中在以下几个点现象可能原因排查方向挂载返回FR_NO_FILESYSTEM扇区没有有效引导记录检查disk_read返回的数据是否正确检查SPI模式配置挂载返回FR_NOT_READY初始化失败或disk_status返回异常用逻辑分析仪抓初始化时序确认CMD0和CMD8有响应读写返回FR_DISK_ERR扇区命令响应超时检查MISO/MOSI是否接反检查SD卡供电是否稳定格式化卡死disk_ioctl的GET_BLOCK_SIZE未正确处理确认GET_BLOCK_SIZE返回一个合理值比如1或5125. 实测性能分析与几个容易被忽略的坑5.1 连续读写的实测速度我把同一颗MK SD NAND分别接到SPI Flash例程改过来的驱动上用正点原子精英板的SPI2最高18MHz做了一组读写测试。单次读写1KB数据块连续读1MB结果大致如下操作平均速度说明连续读512字节扇区约900KB/sSPI时钟18MHz受限于协议开销连续写512字节扇区约450KB/sNAND写入时间约1ms加上SPI传输文件打开/关闭约2~5msFAT表在卡内无需额外缓存这个速度对图片读取、日志记录来说完全够用。举个例子在320x240分辨率下存一张RGB565格式的图片大约150KB从SD NAND里读出来也就不到200ms配合DMA和双缓冲完全可以做到流畅播放幻灯片。如果觉得速度不够可以换成SDIO 4-bit模式理论上读速度能跑到6~8MB/s但代码复杂度会多出不少。这里建议根据项目实际情况权衡不要一上来就追求最高性能稳定可靠才是嵌入式开发的主旋律。5.2 SPI时钟不能一味调快SD卡在SPI模式下最高时钟频率通常规定不超过25MHz而STM32F103的SPI2最高是18MHz理论上在合理范围内。但实际调试时很多人的SPI时钟是从Flash例程里带过来的直接把分频系数设成2跑9MHz甚至有人设成018MHz。这种高速配置在短引线上没问题一旦杜邦线过长、接触不良或者PCB走线不讲究就很容易出现随机读写错误。我的建议是先用低速250kHz~2MHz完整跑一遍读写测试确认所有逻辑没问题后再逐步提高SPI时钟每提升一档都要做一轮连续读写压力测试。很多所谓“玄学报错”最后查出来都是时钟跑太高导致的信号完整性问题的。5.3 掉电和热插拔的注意事项MK SD NAND虽然是贴片芯片不会像TF卡那样被用户随意插拔但在调试过程中还是可能遇到问题。比如说在写文件的过程中直接按复位键或者断掉开发板电源这可能导致FAT表没有及时更新甚至损坏文件系统。解决办法有两个硬件上加一个电源监控芯片比如复位IC确保3.3V电压降到阈值以下之前让MCU完成文件关闭和落盘操作。这在工业级产品上是标配方案。软件层面在写入文件后及时调用f_sync()来刷写缓存降低掉电损坏的风险。要注意的是f_sync()会降低写性能所以更合理的策略是重要数据写入后立即同步普通日志可以攒一批再同步。// 写文件后主动同步到SD NAND防止掉电丢数据 f_write(file, data, len, bw); f_sync(file); // 立即刷写FAT表和缓存5.4 启动模式与调试器的配合精英板的BOOT0引脚默认接低电平从主Flash启动这部分不会影响SD NAND的初始化。但如果你的代码里用到了外部中断、看门狗之类的功能要注意在初始化SD NAND期间可能被看门狗打断导致SPI通讯超时。我在调试时就碰到过一次开着IWDG主循环间隔2秒喂狗但SD卡第一次初始化特别慢低速率循环重试正好卡在1.8秒左右的时候被看门狗复位了。后来把初始化顺序调整了一下先完成SD卡初始化再开看门狗问题就消失了。6. 一些比较实用的进阶玩法和完整工程建议6.1 用电脑预置文件实现真正的“拷入即用”SD NAND一个非常直观的优势是你可以用读卡器把它当成普通SD卡插入电脑直接往里面拷贝文件然后贴回板子上。这意味着可以在量产阶段提前写入默认配置、字库资源、甚至完整的UI图片素材。要做到这一点只需要把SPI模式下的SD NAND接到电脑读卡器接口上吗不对普通读卡器识别的是SD协议你只需要把SD NAND芯片放到对应的SD卡转接板上再插进电脑读卡器即可。市面上有现成的LGA-8转SD卡转接板十几块钱一块对这个工作流来说非常实用。6.2 Bootloader升级固件的思路有了大容量SD NAND固件升级方案也可以做得更优雅。把升级固件比如.bin文件放在SD NAND的某个目录下Bootloader程序上电后先去检查这个文件如果有新版本就从文件里读出数据写到主Flash的应用区然后跳转执行。这个方案比UART/IAP要省事得多尤其适合现场维护场景。检修人员不需要带电脑、不需要接串口线只要把新固件拷贝到SD NAND里给设备重新上电就能完成升级。// Bootloader中读取升级固件并写入Flash的伪代码 res f_open(file, 0:/fw.bin, FA_READ); if (res FR_OK) { while (f_read(file, buf, 2048, br) FR_OK br 0) { FLASH_ErasePage(APP_ADDR offset); FLASH_Write(APP_ADDR offset, buf, br); // 按页编程 offset br; } f_close(file); }6.3 基于此方案的完整工程建议最后给正在动手实践的朋友一个工程组织建议。在正点原子老版标准库例程基础上改造建议把SD驱动单独拆成一个模块文件结构如下SD_Card/ ├── sd.c // SD卡SPI驱动初始化、读扇区、写扇区 ├── sd.h // 驱动头文件 ├── ff.c // FatFs源码 ├── ff.h // FatFs头文件 ├── diskio.c // FatFs底层对接调用sd.c的函数 ├── diskio.h └── ffconf.h // FatFs配置这样做有个直观的好处以后换到其他STM32型号或者换到HAL库工程只需要改sd.c里的SPI底层部分和diskio.c里的接口映射文件系统部分几乎不用动。我现在的项目团队内部就是用这个结构做跨平台复用的从F1到F4再到H7迁移成本很低。另外如果你用的是HAL库正点原子也有相应的HAL库例程SDIO部分已经封装好了只需要把SPI_Flash_ReadByte和SPI_Flash_SendByte替换成HAL库的HAL_SPI_TransmitReceive即可整体思路完全一致。7. 最后谈谈我的实际使用感受玩了大半年MK SD NAND之后我的一个体会是在嵌入式存储方案选型时很多人过度迷信底层控制感总觉得NAND就必须自己写坏块管理、写磨损均衡否则就不够“专业”。但现实是一个稳定可靠、省心省力的方案往往才是产品落地最需要的。SD NAND这种把复杂度封装进内部控制器的思路恰好踩中了这个平衡点。你牺牲了一点点对底层的掌控力换来的却是量产阶段几乎为零的存储部分故障率。在我的几个实际项目里从温湿度记录仪到小型HMI人机界面MK SD NAND都默默无闻地稳定跑着没给我惹过麻烦。当然它也不是万能的。高并发随机写入性能比不上专业eMMC价格也比普通TF卡贵但对于大多数单片机场景来说性能完全溢出、可靠性刚好够用、成本又远低于自研Flash方案的总体思路确实很值得一试。希望这篇实操笔记能帮你在正点原子精英板上少走几步弯路。如果你在自己的板子上跑通了这个方案欢迎交流你遇到的那些奇奇怪怪的坑——尤其是SPI时钟和CS控制这两块永远值得多看两眼。
STM32精英板接入MK SD NAND：SPI驱动与FatFs移植详解
搞嵌入式的人迟早会遇到这么一档子事程序里要存几张图片、一组字库、或者跑一段长时间的运行日志板子上的Flash不够用了外挂SD卡又觉得“杀鸡用牛刀”毕竟卡座要占PCB面积、要买卡、还要考虑接触可靠性。我最早是硬着头皮用SPI Flash一颗一颗往上堆容量后来发现一颗国产的MK SD NAND就能把问题解决得挺干净而且驱动起来并不比Flash复杂多少。这次就用正点原子STM32精英板把整个跑通过程拆成三步给大家做个参考。说的MK SD NAND其实就是把NAND Flash颗粒和SD控制器封装在一颗芯片里对外直接提供SD协议接口。你不用管坏块管理、擦写均衡、ECC校验这些底层破事把它当成一张贴片式的SD卡就行。这对于习惯裸机开发、又不想为Flash写复杂FTL算法的团队来说非常省心。正点原子精英板上的主控是STM32F103ZET6板载资源里有SDIO接口和SPI接口搭配MK SD NAND跑FatFs文件系统在标准库和HAL库环境下都能比较轻松地实现。这篇文章适合谁看呢正好在用正点原子精英板、或者手头有类似STM32F1/F4系列板子的人想给项目加一个容量可观128MB到数GB、还不用占太大面积的存储方案同时对只跑过W25Q系列的SPI Flash、没碰过SD协议的人也很友好。下面按我的实操顺序从选型认知讲到底层驱动再到文件系统挂载一步步说清楚。1. MK SD NAND到底解决了什么问题1.1 一颗芯片替代一张卡槽的思维转变很多人第一次听到SD NAND第一反应是“这不就是个没有外壳的SD卡吗”。话糙理不糙但这里面的门道远不止“省掉外壳”这么简单。SD NAND在封装形式上直接做成LGA-8贴片封装能用SMT贴片机直接打在PCB上不需要卡座、不需要买TF卡、不需要考虑用户插拔方向。这对于量产产品来说整个BOM和生产环节都省了不少事。更重要的是可靠性和一致性。独立的SD卡是消费品卡的质量参差不齐跑一段时间出现坏块、掉速甚至数据丢失是常有的事。而SD NAND出厂前经过了筛选和初始化控制器内置了坏块管理和磨损均衡对主控芯片来说它就是一个标准SD设备不需要你额外写Flash管理算法。以MK系列常见的容量为例单颗就能做到128MB到数GB冗余度要比常见板载Flash大得多。另外一个小优势很多人可能没意识到它占用的是标准SD协议也就意味着主控端无论是用SDIO、还是用SPI都能访问。这对于引脚紧张的板子非常友好。F103ZET6虽然不缺引脚但如果你用的是小封装的F103C8T6之类的芯片SPI模式接四根线就能获得一个几百MB的存储空间性价比极高。1.2 MK SD NAND与SD卡、SPI Flash的核心差异这三个东西放在一起对比能帮你快速判断什么场景该选谁对比维度MK SD NANDTF卡 卡座板载SPI Flash封装形式LGA-8贴片适合量产插拔式适合开发调试SOP-8等贴片封装接口协议SDIO / SPISDIO / SPISPI容量上限数百MB至数GB数GB至数十GB通常8MB~64MB坏块管理内置控制器处理由卡内部处理需要自研或依赖库磨损均衡内置依卡品质而定需要自研占用PCB面积极小较大含卡座小BOM成本中等低但卡品质不可控低从表格能看出来SPI Flash的唯一优势是价格便宜、电路简单但容量一大成本反而会比SD NAND更高而且代码复杂度陡增。TF卡的优势是灵活、替换方便可它最大的软肋是插拔接触和品质一致性。生产过产品的人都有体会卡座带来的售后问题远比你想象得多。1.3 它适合跑在什么场景里结合我自己的项目经验以下几个场景用MK SD NAND特别合适存储GUI图片资源、字库文件。比如用LVGL做界面图片资源动辄几MB到几十MB放SD NAND里按需从文件系统读取既节省Flash又不占用RAM。长时间数据采集与日志记录。传感器数据、GPS轨迹、故障日志配上FatFs按天建文件存储上完全不用操心容量。音频播放。比如语音提示、短音频回放数据量在几十MB级别SD NAND的连续读速度比SPI Flash快得多。轻量级文件交换。设备配置参数、升级固件包直接在电脑上将文件通过读卡器写进SD NAND设备上电就能解析。这一点在实际产线上很有用比用专用烧录器方便。2. 精英板上的SPI接线与SDIO方案取舍2.1 为什么我最终选了SPI模式而不是SDIO精英板板载的SD卡座默认用的是SDIO 4-bit模式而SDIO接口在F103上需要复用PB8~PB11等引脚同时要额外准备一个DMA通道来搬运数据底层代码量明显上了一个台阶。如果你的核心诉求是“快速跑通”和“理解协议”SPI模式是最直接的选择。SPI模式有几个不可替代的好处引脚占用少只要SCK、MISO、MOSI、CS四根线外加电源和地一共六根线就能跑。代码复用度高正点原子例程里面的SPI Flash驱动框架可以直接改造成SD卡驱动底层就换个命令集合而已。调试方便SPI时序可以用逻辑分析仪直接抓出问题时定位比SDIO快得多。当然SPI模式读取速度确实不及SDIO理论上SPI时钟跑到18MHz时读速度大约能到1~2MB/s写速度更慢一些。对于只存图片、字库、日志这类对实时性要求不高的场景这个速度完全够用。真要做高速音视频流再考虑上SDIO 4-bit模式不迟。2.2 引脚对应关系与接线图正点原子精英板上引出的SPI2接口在板子背面或者右侧排针处能查到对应的引脚关系如下MK SD NAND引脚功能精英板引脚说明CS片选PB12SPI2_NSS软件控制SCK时钟PB13SPI2_SCKMISO主入从出PB14SPI2_MISOMOSI主出从入PB15SPI2_MOSIVCC电源3.3V典型供电3.3V注意别接5VGND地GND共地接线时有两个必须注意的地方千万不要把VCC接到5V上。虽然有些SD卡模块带电平转换支持5V供电但SD NAND芯片本身是纯粹的3.3V器件接了5V轻则工作不稳定重则直接烧掉。CS引脚建议用普通GPIO控制不要用SPI外设的硬件NSS。原因是硬件NSS在通讯异常时可能被拉低导致SD卡误进入SPI模式增加排查难度。软件控制CS最省心读写前拉低结束后拉高。2.3 精英板上跑SPI需要额外注意的电平细节STM32F103的GPIO是5V容忍的但SD NAND不是。虽然SPI是3.3V逻辑电平与F103的IO电平匹配没有问题但在调试时有些细节容易被忽略。比如上电顺序。如果先给STM32供电再给SD NAND模块供电可能出现IO口高电平灌入未上电芯片的情况。实际接线上只要VCC用同一个3.3V来源上电顺序问题基本可以忽略但如果你用的是外部独立供电模块最好在MCU初始化SPI引脚时先把它们设为浮空输入等确认供电稳定后再配置为复用推挽输出。另一个容易被忽略的点是SD卡协议要求SPI模式下SCK的默认状态是低电平CPOL0数据在第一个时钟沿采样CPHA1也就是SPI模式3。这个在后面配置寄存器时会用到千万别配成模式0或者模式2否则命令发出去基本石沉大海。提示正点原子精英板的板载SD卡座和SPI Flash复用了一部分引脚如果你同时插了SD卡又外挂了SD NAND模块可能产生总线冲突。做实验时优先确保只有一个设备挂在同一条SPI总线上。3. SPI驱动改造从Flash例程到SD卡命令集的迁移3.1 SD卡在SPI模式下的初始化流程SD卡的初始化流程和SPI Flash完全不同这也是从Flash转过来的人最容易卡住的地方。简单来说SD卡上电后首先进入的是SD模式必须发送特定序列的命令把它切换到SPI模式然后才能进行后续的容量读取和读写操作。整个初始化过程可以拆成以下几个步骤上电后先给SD卡至少74个时钟周期让它完成内部上电复位。实际操作时可以直接发送80个字节的0xFF来保证时钟数足够。发送CMD00x40同时把CS引脚拉低。SD卡收到CMD0后应答0x01表示进入空闲状态Idle State。发送CMD80x48检查卡是否支持SD V2.0协议。这条命令的响应低32位如果是0x1AA说明卡支持2.0协议是SD NAND最常见的应答。循环发送CMD55ACMD410x77, 0x69, 然后CMD41为0x69组合直到响应变为0x00表示卡退出空闲状态完成初始化。读取OCR寄存器、CSD寄存器确认卡的容量和扇区信息。你可能会问为什么初始化序列这么啰嗦因为SD协议本身要兼容不同厂家、不同代的卡。CMD8负责探测协议版本ACMD41负责协商工作电压范围、使能卡内部上电整个过程就是“握手-确认身份-协商参数”的流程。用生活化的类比这就像两个陌生人要合作得先互报家门确认身份再谈好合作条件最后才能开始干活。3.2 在正点原子SPI Flash驱动框架上改造命令函数正点原子标准库例程里的SPI Flash驱动底层有SPI_Flash_ReadByte()和SPI_Flash_SendByte()这两个函数这是整个驱动的基础。SD卡驱动也一样只不过SD卡需要额外的CS控制和命令响应处理。下面是SD卡SPI驱动中几个核心函数的代码实现可以直接替换掉原来Flash驱动里的对应逻辑// 发送一个命令给SD卡cmd为命令索引arg为参数crc为CRC校验 u8 SD_SendCmd(u8 cmd, u32 arg, u8 crc) { u8 r1; // 片选拉低开始传输 SD_CS_LOW(); // 发送起始位和命令索引格式为01xxxxxx SPI_Flash_SendByte(cmd | 0x40); // 发送参数大端序 SPI_Flash_SendByte(arg 24); SPI_Flash_SendByte(arg 16); SPI_Flash_SendByte(arg 8); SPI_Flash_SendByte(arg); // 发送CRCCMD0和CMD8这些特殊命令需要有效CRC其余可发送0xFF SPI_Flash_SendByte(crc); } // 接收SD卡返回的R1响应 u8 SD_GetResponse(u8 Response) { u16 i 0; // 一直读直到收到想要的响应超时退出 while (i 0x0FFF) { u8 r SPI_Flash_ReadByte(); if (r Response) { return 0; // 获取成功 } i; } return 1; // 超时失败 }初始化函数里最关键的是发送CMD0之前要先把SPI时钟降到400kHz以下等卡完成初始化后再提高到最高速率。这一点新手特别容易忽略一上来就用高速时钟发CMD0卡根本不响应。原因在于SD卡协议规定SD卡唤醒和识别阶段必须工作在低速模式下高速率是初始化完成之后才允许的事。我实际调试时踩过这个坑一开始用2MHz的SPI时钟发CMD0连续几天都读不回0x01最后把时钟降到250kHz一发就通了。从那时起我养成了习惯凡是初始化序列一律先低速跑判断完卡类型再切高速。3.3 初始化完整代码参考把上面的命令发送函数串起来就是完整的SD卡初始化流程u8 SD_Init(void) { u8 r1; u16 i; // 初始化SPI2设置低速模式 SPI2_Init(); // 释放CS并发送至少74个时钟周期的0xFF SD_CS_HIGH(); for (i 0; i 10; i) { SPI_Flash_SendByte(0xFF); } // 片选拉低正式进入SPI模式 SD_CS_LOW(); // 发送CMD0进入空闲态 SD_SendCmd(0, 0, 0x95); // CMD0的CRC固定为0x95 r1 SD_GetResponse(0x01); // 期望收到0x01 if (r1 ! 0) return 1; // CMD0失败 // 发送CMD8检查卡类型 SD_SendCmd(8, 0x000001AA, 0x87); // CMD8的CRC固定为0x87 r1 SD_GetResponse(0x01); if (r1 ! 0) return 2; // 不支持SD V2.0 // 读取CMD8的后32位检查是否为0x1AA for (i 0; i 4; i) { u8 tmp SPI_Flash_ReadByte(); if ((i 2) (tmp ! 0x01)) return 3; if ((i 3) (tmp ! 0xAA)) return 4; } // 循环发送ACMD41直到卡就绪 for (i 0; i 200; i) { SD_SendCmd(55, 0, 0x01); // 先发CMD55表示下一条是应用命令 SD_GetResponse(0x01); SD_SendCmd(41, 0x40000000, 0x01); // HCS1表示支持高容量卡 r1 SD_GetResponse(0x00); // 期望收到0x00 if (r1 0) break; // 卡初始化完成 delay_ms(10); // 没就绪就等一会儿再试 } if (i 200) return 5; // 初始化超时 // 读取CSD寄存器获取卡容量信息略后面单独说明 SD_ReadCSD(); // 切换SPI为高速模式 SPI2_SetSpeed(SPI_SPEED_18M); return 0; // 初始化成功 }提示代码里SD_CS_LOW()和SD_CS_HIGH()是软件控制PB12的宏别直接替换成Flash的片选控制。很多人在移植时把片选搞混导致SD卡一直处于选中或非选中状态初始化自然过不去。3.4 读CSD寄存器获取容量信息SD卡的容量信息藏在CSD寄存器里不同版本协议解析方法不一样。SD V2.0的高容量卡CSD版本为1容量计算公式比较简单// 读取CSD寄存器的前16个字节 u8 csd[16]; u8 SD_ReadCSD(void) { u8 i; SD_SendCmd(9, 0, 0x01); // CMD9读取CSD u8 r1 SD_GetResponse(0x00); if (r1 ! 0) return 1; // 等待数据起始令牌0xFE u16 timeout 0; while ((SPI_Flash_ReadByte() ! 0xFE) (timeout 0xFFFF)) timeout; if (timeout 0xFFFF) return 2; // 读取16字节CSD数据 for (i 0; i 16; i) csd[i] SPI_Flash_ReadByte(); // 跳过2字节CRC SPI_Flash_ReadByte(); SPI_Flash_ReadByte(); return 0; } // 解析CSD获取容量单位KB u32 SD_GetCapacityKB(void) { if ((csd[0] 6) 1) { // SD V2.0高容量卡C_SIZE为csd[8]的低2位 csd[9] csd[10]的高6位 u32 c_size ((csd[8] 0x3F) 16) | (csd[9] 8) | csd[10]; return (c_size 1) * 1024; // 单位是KB } else { // 旧版SD卡/标准容量卡解析方式不同 u32 c_size ((csd[6] 0x03) 10) | (csd[7] 2) | ((csd[8] 0xC0) 6); u32 c_size_mult ((csd[9] 0x03) 1) | ((csd[10] 0x80) 7); u32 read_bl_len csd[5] 0x0F; return (u32)((c_size 1) * (1 (c_size_mult 2)) * (1 read_bl_len)) / 1024; } }这里有个小细节CSD寄存器的数据读取过程有一个0xFE数据起始令牌函数里用了超时循环这种超时机制在后面读扇区时也会用到。4. 文件系统接入FatFs在精英板上的移植要点4.1 为什么选择FatFs而不是其他文件系统SD NAND的底层驱动打通了接下来自然要建文件系统。目前STM32界最主流的方案就是FatFs几乎没有之一。它占用资源少原生支持FAT32跟Windows兼容性好在嵌入式领域算得上是事实标准。有人可能问LittleFS不是也很火吗LittleFS的优势在于掉电安全和磨损均衡但它是日志结构的文件系统Windows无法直接识别要配合专用工具才能在电脑上读取里面的文件。而FatFs的好处是你直接把SD NAND在电脑上格式化好再插回板子上程序就能直接读。对于MK SD NAND这种内置了坏块管理和磨损均衡的芯片FatFs的劣势反而没那么明显。芯片在底层已经帮我们做了大量Flash管理文件系统层面只要正常挂载、读写就行经典的FatFs方案是最稳妥、最少坑的选择。4.2 diskio底层接口对接FatFs官方源码包里有五个底层接口需要实现对应到SD卡驱动就是FatFs接口作用SD驱动映射disk_initialize初始化磁盘调用SD_Init()disk_status获取磁盘状态返回STA_NOINIT或0disk_read读取扇区调用SD_ReadDisk()disk_write写入扇区调用SD_WriteDisk()disk_ioctl控制命令实现GET_SECTOR_COUNT等disk_read和disk_write是最核心的两个函数。SD卡在SPI模式下以扇区为单位读写数据每个扇区512字节读写前需要发送命令等待数据令牌然后连续传输512字节最后还有2字节CRC需要接收或发送。读扇区函数的代码实现如下u8 SD_ReadDisk(u8 *buf, u32 sector, u8 cnt) { u8 r1; u16 i; u16 timeout; for (i 0; i cnt; i) { // 发送CMD17读取单扇区 SD_SendCmd(17, sector i, 0x01); r1 SD_GetResponse(0x00); if (r1 ! 0) { return 1; // 命令响应超时 } // 等待数据起始令牌0xFE timeout 0; while ((SPI_Flash_ReadByte() ! 0xFE) (timeout 0xFFFF)) timeout; if (timeout 0xFFFF) return 2; // 等待数据超时 // 读取512字节数据 for (u16 j 0; j 512; j) { buf[i * 512 j] SPI_Flash_ReadByte(); } // 跳过2字节CRC SPI_Flash_ReadByte(); SPI_Flash_ReadByte(); } return 0; }写扇区稍微有点不同需要发送CMD24写单扇区然后先发送数据起始令牌0xFE再连续发送512字节数据最后发送2字节CRCSPI模式下发送0xFF即可然后读取芯片返回的数据响应字节检查是0x05数据接受还是0x0B数据拒绝。4.3 FatFs配置选项的合理设置FatFs源码中的ffconf.h配置文件直接决定了文件系统的大小和功能有几个选项必须根据SD NAND的特性来调整#define FF_USE_MKFS 1 // 允许格式化 #define FF_USE_STRFUNC 1 // 允许文件流函数 #define FF_USE_LFN 2 // 支持长文件名动态内存 #define FF_FS_MINIMUM 0 // 全功能模式 #define FF_FS_RPATH 1 // 支持相对路径其中FF_USE_LFN建议设置为2使用动态内存分配长文件名缓冲区可以显著节省RAM占用。如果工程里RAM吃紧也可以设置为1用静态数组但要注意数组大小要足够大至少256字节。另外一个容易踩坑的配置项是FF_USE_MKFS。如果你希望程序运行时能直接格式化SD NAND比如首次上电发现没有文件系统时自动格式化必须把这个宏设为1并且在disk_ioctl里正确实现GET_SECTOR_COUNT、GET_BLOCK_SIZE这两个命令否则f_mkfs()会失败或直接死循环。4.4 文件读写测试与常见报错排查移植完成后写个简单的测试函数验证一下整条链路是否通畅void FATFS_Test(void) { FATFS fs; FIL file; UINT bw, br; FRESULT res; // 挂载文件系统 res f_mount(fs, 0:, 1); if (res FR_NO_FILESYSTEM) { // 没有文件系统格式化 res f_mkfs(0:, 0, 0); if (res ! FR_OK) { printf(Format failed: %d\r\n, res); return; } res f_mount(fs, 0:, 1); } if (res ! FR_OK) { printf(Mount failed: %d\r\n, res); return; } // 写文件测试 res f_open(file, test.txt, FA_CREATE_ALWAYS | FA_WRITE); if (res FR_OK) { char *data Hello MK SD NAND!\r\n; f_write(file, data, strlen(data), bw); f_close(file); printf(Write %d bytes\r\n, bw); } else { printf(Open failed: %d\r\n, res); } // 读文件测试 res f_open(file, test.txt, FA_READ); if (res FR_OK) { char buf[64] {0}; f_read(file, buf, sizeof(buf) - 1, br); f_close(file); printf(Read %d bytes: %s\r\n, br, buf); } else { printf(Open failed: %d\r\n, res); } // 注销文件系统 f_mount(NULL, 0:, 1); }如果这个测试函数跑下来能正确打印出“Hello MK SD NAND!”这一行恭喜你整条链路已经通了。如果在过程中遇到问题大部分都集中在以下几个点现象可能原因排查方向挂载返回FR_NO_FILESYSTEM扇区没有有效引导记录检查disk_read返回的数据是否正确检查SPI模式配置挂载返回FR_NOT_READY初始化失败或disk_status返回异常用逻辑分析仪抓初始化时序确认CMD0和CMD8有响应读写返回FR_DISK_ERR扇区命令响应超时检查MISO/MOSI是否接反检查SD卡供电是否稳定格式化卡死disk_ioctl的GET_BLOCK_SIZE未正确处理确认GET_BLOCK_SIZE返回一个合理值比如1或5125. 实测性能分析与几个容易被忽略的坑5.1 连续读写的实测速度我把同一颗MK SD NAND分别接到SPI Flash例程改过来的驱动上用正点原子精英板的SPI2最高18MHz做了一组读写测试。单次读写1KB数据块连续读1MB结果大致如下操作平均速度说明连续读512字节扇区约900KB/sSPI时钟18MHz受限于协议开销连续写512字节扇区约450KB/sNAND写入时间约1ms加上SPI传输文件打开/关闭约2~5msFAT表在卡内无需额外缓存这个速度对图片读取、日志记录来说完全够用。举个例子在320x240分辨率下存一张RGB565格式的图片大约150KB从SD NAND里读出来也就不到200ms配合DMA和双缓冲完全可以做到流畅播放幻灯片。如果觉得速度不够可以换成SDIO 4-bit模式理论上读速度能跑到6~8MB/s但代码复杂度会多出不少。这里建议根据项目实际情况权衡不要一上来就追求最高性能稳定可靠才是嵌入式开发的主旋律。5.2 SPI时钟不能一味调快SD卡在SPI模式下最高时钟频率通常规定不超过25MHz而STM32F103的SPI2最高是18MHz理论上在合理范围内。但实际调试时很多人的SPI时钟是从Flash例程里带过来的直接把分频系数设成2跑9MHz甚至有人设成018MHz。这种高速配置在短引线上没问题一旦杜邦线过长、接触不良或者PCB走线不讲究就很容易出现随机读写错误。我的建议是先用低速250kHz~2MHz完整跑一遍读写测试确认所有逻辑没问题后再逐步提高SPI时钟每提升一档都要做一轮连续读写压力测试。很多所谓“玄学报错”最后查出来都是时钟跑太高导致的信号完整性问题的。5.3 掉电和热插拔的注意事项MK SD NAND虽然是贴片芯片不会像TF卡那样被用户随意插拔但在调试过程中还是可能遇到问题。比如说在写文件的过程中直接按复位键或者断掉开发板电源这可能导致FAT表没有及时更新甚至损坏文件系统。解决办法有两个硬件上加一个电源监控芯片比如复位IC确保3.3V电压降到阈值以下之前让MCU完成文件关闭和落盘操作。这在工业级产品上是标配方案。软件层面在写入文件后及时调用f_sync()来刷写缓存降低掉电损坏的风险。要注意的是f_sync()会降低写性能所以更合理的策略是重要数据写入后立即同步普通日志可以攒一批再同步。// 写文件后主动同步到SD NAND防止掉电丢数据 f_write(file, data, len, bw); f_sync(file); // 立即刷写FAT表和缓存5.4 启动模式与调试器的配合精英板的BOOT0引脚默认接低电平从主Flash启动这部分不会影响SD NAND的初始化。但如果你的代码里用到了外部中断、看门狗之类的功能要注意在初始化SD NAND期间可能被看门狗打断导致SPI通讯超时。我在调试时就碰到过一次开着IWDG主循环间隔2秒喂狗但SD卡第一次初始化特别慢低速率循环重试正好卡在1.8秒左右的时候被看门狗复位了。后来把初始化顺序调整了一下先完成SD卡初始化再开看门狗问题就消失了。6. 一些比较实用的进阶玩法和完整工程建议6.1 用电脑预置文件实现真正的“拷入即用”SD NAND一个非常直观的优势是你可以用读卡器把它当成普通SD卡插入电脑直接往里面拷贝文件然后贴回板子上。这意味着可以在量产阶段提前写入默认配置、字库资源、甚至完整的UI图片素材。要做到这一点只需要把SPI模式下的SD NAND接到电脑读卡器接口上吗不对普通读卡器识别的是SD协议你只需要把SD NAND芯片放到对应的SD卡转接板上再插进电脑读卡器即可。市面上有现成的LGA-8转SD卡转接板十几块钱一块对这个工作流来说非常实用。6.2 Bootloader升级固件的思路有了大容量SD NAND固件升级方案也可以做得更优雅。把升级固件比如.bin文件放在SD NAND的某个目录下Bootloader程序上电后先去检查这个文件如果有新版本就从文件里读出数据写到主Flash的应用区然后跳转执行。这个方案比UART/IAP要省事得多尤其适合现场维护场景。检修人员不需要带电脑、不需要接串口线只要把新固件拷贝到SD NAND里给设备重新上电就能完成升级。// Bootloader中读取升级固件并写入Flash的伪代码 res f_open(file, 0:/fw.bin, FA_READ); if (res FR_OK) { while (f_read(file, buf, 2048, br) FR_OK br 0) { FLASH_ErasePage(APP_ADDR offset); FLASH_Write(APP_ADDR offset, buf, br); // 按页编程 offset br; } f_close(file); }6.3 基于此方案的完整工程建议最后给正在动手实践的朋友一个工程组织建议。在正点原子老版标准库例程基础上改造建议把SD驱动单独拆成一个模块文件结构如下SD_Card/ ├── sd.c // SD卡SPI驱动初始化、读扇区、写扇区 ├── sd.h // 驱动头文件 ├── ff.c // FatFs源码 ├── ff.h // FatFs头文件 ├── diskio.c // FatFs底层对接调用sd.c的函数 ├── diskio.h └── ffconf.h // FatFs配置这样做有个直观的好处以后换到其他STM32型号或者换到HAL库工程只需要改sd.c里的SPI底层部分和diskio.c里的接口映射文件系统部分几乎不用动。我现在的项目团队内部就是用这个结构做跨平台复用的从F1到F4再到H7迁移成本很低。另外如果你用的是HAL库正点原子也有相应的HAL库例程SDIO部分已经封装好了只需要把SPI_Flash_ReadByte和SPI_Flash_SendByte替换成HAL库的HAL_SPI_TransmitReceive即可整体思路完全一致。7. 最后谈谈我的实际使用感受玩了大半年MK SD NAND之后我的一个体会是在嵌入式存储方案选型时很多人过度迷信底层控制感总觉得NAND就必须自己写坏块管理、写磨损均衡否则就不够“专业”。但现实是一个稳定可靠、省心省力的方案往往才是产品落地最需要的。SD NAND这种把复杂度封装进内部控制器的思路恰好踩中了这个平衡点。你牺牲了一点点对底层的掌控力换来的却是量产阶段几乎为零的存储部分故障率。在我的几个实际项目里从温湿度记录仪到小型HMI人机界面MK SD NAND都默默无闻地稳定跑着没给我惹过麻烦。当然它也不是万能的。高并发随机写入性能比不上专业eMMC价格也比普通TF卡贵但对于大多数单片机场景来说性能完全溢出、可靠性刚好够用、成本又远低于自研Flash方案的总体思路确实很值得一试。希望这篇实操笔记能帮你在正点原子精英板上少走几步弯路。如果你在自己的板子上跑通了这个方案欢迎交流你遇到的那些奇奇怪怪的坑——尤其是SPI时钟和CS控制这两块永远值得多看两眼。 
