STM32 FatFS连续写入SD卡数据丢失？3个常见坑点与实战修复方案
STM32 FatFS连续写入SD卡数据丢失？3个常见坑点与实战修复方案
最近在调试STM32的SD卡数据记录功能时，遇到了一个让人头疼的问题：使用FatFS库连续写入数据时，SD卡中的文件要么是空的，要么全是乱码。经过一番折腾，终于找到了问题的根源。如果你也遇到了类似的情况，这篇文章或许能帮你少走弯路。
1. 参数设置错误：FA_CREATE_ALWAYS的陷阱
刚开始使用FatFS时，我习惯性地在f_open()函数中使用了FA_CREATE_ALWAYS参数，结果每次写入都会覆盖之前的数据。这个参数会强制创建一个新文件，即使同名文件已经存在。对于需要连续写入数据的场景，这显然是个大坑。
正确的做法是：
// 错误示例 - 会覆盖已有文件 f_open(&file, "data.txt", FA_CREATE_ALWAYS | FA_WRITE); // 正确示例 - 打开现有文件准备写入 f_open(&file, "data.txt", FA_WRITE);关键点对比：
| 参数 | 行为 | 适用场景 |
|---|---|---|
| FA_CREATE_ALWAYS | 总是创建新文件 | 单次写入 |
| FA_WRITE | 打开现有文件 | 连续写入 |
| FA_OPEN_EXISTING | 仅打开已有文件 | 读取或追加 |
提示：首次打开文件时，可以组合使用FA_OPEN_EXISTING和FA_WRITE，确保不会意外创建新文件。
2. 文件同步问题：为什么数据会丢失
在调试过程中，我发现即使正确写入了数据，断电后文件内容还是会丢失。这是因为FatFS采用了缓存机制，数据不会立即写入物理存储。这就好比在电脑上编辑文档后没有按Ctrl+S保存。
解决方法有两种：
- 使用f_sync()强制同步缓存
- 使用f_close()关闭文件（会自动调用f_sync()）
推荐的工作流程：
// 打开文件 f_open(&file, "data.txt", FA_WRITE); // 写入数据 f_printf(&file, "%s\r\n", sensor_data); // 立即同步到SD卡 f_sync(&file); // 或者直接关闭文件 f_close(&file);3. 指针偏移问题：为什么只有最后一行数据
最让人困惑的情况是，明明调用了多次写入函数，但文件里只有最后一次写入的数据。这通常是因为文件指针没有正确移动，导致每次都在同一个位置写入。
解决方法很简单：在每次写入前，将指针移动到文件末尾：
// 将指针移动到文件末尾 f_lseek(&file, f_size(&file)); // 然后写入新数据 f_write(&file, new_data, strlen(new_data), &bytes_written);完整连续写入示例：
// 初始化阶段 f_open(&file, "log.txt", FA_WRITE | FA_OPEN_APPEND); while(1) { // 获取传感器数据 get_sensor_data(buffer); // 写入数据 f_printf(&file, "%s\r\n", buffer); // 定期同步 if(++count % 10 == 0) { f_sync(&file); } // 适当延时 HAL_Delay(1000); } // 最终关闭 f_close(&file);4. 高级技巧与性能优化
对于需要高频写入的场景，频繁打开/关闭文件或调用f_sync()会影响性能。这里分享几个优化建议：
- 批量写入：收集一定量数据后一次性写入，减少IO操作次数
- 定时同步：每N次写入执行一次f_sync()，平衡数据安全性和性能
- 错误处理：检查每个函数调用的返回值，确保操作成功
错误处理示例：
FRESULT res; res = f_open(&file, "data.txt", FA_WRITE); if(res != FR_OK) { // 处理错误 error_handler(res); } res = f_lseek(&file, f_size(&file)); if(res != FR_OK) { // 处理错误 error_handler(res); }在实际项目中，我还发现SD卡的质量和格式化方式也会影响稳定性。建议使用官方工具格式化SD卡为FAT32格式，分配单元大小设为32KB或64KB以获得最佳性能。