[大问题的解决！]！！！用FatFS的朋友们注意了啊，福利来了！

光圈电子科技-晓航-多多实验室 · 发表于 2014-7-18 20:46:53

以前用FatFS的时候有没有发现在使用大容量卡（4G以上）的时候，卡里存了4G以上的东西，新存的文件就不能被正确读取了呢？！
这是因为大家移植的FatFS都是32位寻址的，只能读到4G以下地址的东西，4G以上的东西虽然文件分配表还有分配，但是却没有这么大的地址去读取。
怎么办呢？让我们来解决这个问题吧！

首先，打开SDIO/SPI总线驱动SD卡的底层文件：

sd.h-------------------
sd.c-------------------

在文件里找到下面的几个函数（类似的也行）：
SD_Error SD_ReadBlock(uint8_t *readbuff, uint32_t ReadAddr, uint16_t BlockSize);
SD_Error SD_ReadMultiBlocks(uint8_t *readbuff, uint32_t ReadAddr, uint16_t BlockSize, uint32_t NumberOfBlocks);
SD_Error SD_WriteBlock(uint8_t *writebuff, uint32_t WriteAddr, uint16_t BlockSize);
SD_Error SD_WriteMultiBlocks(uint8_t *writebuff, uint32_t WriteAddr, uint16_t BlockSize, uint32_t NumberOfBlocks);

看到Addr的参数了吗？这是地址，现在我们把它改成64位的，像这样：

SD_Error SD_ReadBlock(uint8_t *readbuff, uint64_t ReadAddr, uint16_t BlockSize);
SD_Error SD_ReadMultiBlocks(uint8_t *readbuff, uint64_t ReadAddr, uint16_t BlockSize, uint32_t NumberOfBlocks);
SD_Error SD_WriteBlock(uint8_t *writebuff, uint64_t WriteAddr, uint16_t BlockSize);
SD_Error SD_WriteMultiBlocks(uint8_t *writebuff, uint64_t WriteAddr, uint16_t BlockSize, uint32_t NumberOfBlocks);

现在，SD卡的底层就改造好了，我们接着改造FatFS：
打开FatFS目录下的integer.h

找到下面几行代码：
/* These types must be 32-bit integer */
typedef long LONG;
typedef unsigned long ULONG;
typedef unsigned long DWORD;

现在稍稍修改一下，变成这样：
/* These types must be 64-bit integer */
typedef long long LONG;
typedef unsigned long long ULONG;
typedef unsigned long long DWORD;

就是把unsigned long 无符号长整型变成unsigned long long 无符号64位长整型。
现在整体改造完毕，可以试试往SD卡里先写5~6G数据，然后再写个文本，现在读就不会读出乱码啦！
原先32位寻址时，最大支持4GBytes的寻址，现在的寻址空间扩大了4294967295倍，你的SD卡再怎么大都不会出错啦！

正点原子 · 发表于 2014-7-21 23:58:47

没问题的，对大容量卡来说，这里是要除以512，再送给ARG的。
具体看代码：

[mw_shl_code=c,true]//SD卡写多个块 //buf:数据缓存区 //addr:写地址 //blksize:块大小 //nblks:要写入的块数 //返回值:错误状态 SD_Error SD_WriteMultiBlocks(u8 *buf,long long addr,u16 blksize,u32 nblks) { SD_Error errorstatus = SD_OK; u8 power = 0, cardstate = 0; u32 timeout=0,bytestransferred=0; u32 count = 0, restwords = 0; u32 tlen=nblks*blksize; //总长度(字节) u32 *tempbuff = (u32*)buf; if(buf==NULL)return SD_INVALID_PARAMETER; //参数错误 SDIO->DCTRL=0x0; //数据控制寄存器清零(关DMA) SDIO_Send_Data_Cfg(SD_DATATIMEOUT,0,0,0); //清除DPSM状态机配置 if(SDIO->RESP1&SD_CARD_LOCKED)return SD_LOCK_UNLOCK_FAILED;//卡锁了 if(CardType==SDIO_HIGH_CAPACITY_SD_CARD)//大容量卡 { blksize=512; addr>>=9; } [/mw_shl_code]

看到那个>>9了么？

就是除以512.
另外，我实测16GB,8GB SD卡，都很好的读写，没有任何问题。

西门吹雪 · 发表于 2014-7-19 07:49:37

赞！！学习了。。。

Admin · 发表于 2014-7-18 22:18:31

谢谢分享、、、

正点原子 · 发表于 2014-7-18 22:48:39

谢谢分享....

正点原子 · 发表于 2014-7-18 22:50:07

我也分享一点今天发现的经验.
fatfs V0.10a以及V0.10b存在一个bug
就是fclose/fclosedir之后,没有调用LEAVE_FF;
如果用了OS,那么很容易导致OS崩溃.
建议大家遇到这个问题的时候,自行加上LEAVE_FF就好了.

jinstm32 · 发表于 2014-7-19 11:13:43

分享是要赞的

498650771 · 发表于 2014-7-19 22:00:08

学习，mark

KC_CEC · 发表于 2014-7-21 13:57:07

不知道楼主你怎么测试通过的，其实这样改是不行的：

根据SD卡读函数来说明一点问题：（我用的stm32f407,1.0的库）
SD_Error SD_ReadBlock(uint8_t *readbuff, uint32_t ReadAddr, uint16_t BlockSize)
若将uint32_t ReadAddr改为uint64_t ReadAddr 是远远不够的,因为
1、查看其内部代码,有一句结构体赋值：
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)ReadAddr;
其中SDIO_Argument 参数也是uint32_t类型的
那么继续往回找，就会发现这个参数是赋值给其内部寄存器的：
SDIO->ARG = SDIO_CmdInitStruct->SDIO_Argument;

查看stm32f4手册可以知道，寄存器ARG是32位的。
也就是说从硬件理论上来说,都是不能寻址64位地址的。

KC_CEC · 发表于 2014-7-21 14:07:32

回复【4楼】正点原子:
---------------------------------
原子哥，麻烦解答一下是不是我哪里搞错了？

KC_CEC · 发表于 2014-7-22 09:11:11

回复【10楼】正点原子:
---------------------------------
分析得真好，赞！

光圈电子科技-晓航-多多实验室 · 发表于 2014-7-22 10:35:45

回复【8楼】KC_CEC:
---------------------------------
没有问题哦，我的FatFS仿真的时候地址存在r2寄存器（32位），因为SDHC卡是有Block的，所以一个地址可以对应一大片扇区的吧

高粱是哪个梁 · 发表于 2014-8-3 20:34:30

赞个。。。。。。

wwwzfgcom · 发表于 2015-2-6 14:21:38

回复【4楼】正点原子:
---------------------------------
FRESULT f_closedir ，和 FRESULT f_close

都有个
#if _FS_REENTRANT
unlock_fs(fs, FR_OK); /* Unlock volume */
#endif
应该没问题吧。

正点原子 · 发表于 2015-2-6 23:21:16

回复【14楼】wwwzfgcom:
---------------------------------
没问题。

z1234zz · 发表于 2015-2-7 09:11:54

提示: 作者被禁止或删除内容自动屏蔽

mahongtu0204 · 发表于 2015-5-20 09:26:56

SD卡的操作单位不是扇区么？32位的地址不是代表扇区的地址么？
所以当判断是大容量（大于4G的时候），不就是扇区的地址了么？既然是扇区的地址，那32位就足够了吧？
因为扇区512字节*2的32次方的容量已经超大了啊
请问我说的对不？

STM32VBT6 · 发表于 2015-5-20 10:24:38

回复【17楼】mahongtu0204:
---------------------------------
mark~~~~~
从楼主的函数来看，应该使用SDIO的时候才需要这么做，因为输入的 ReadAddr是字节地址；
而使用SPI 方式的时候则无需修改，因为 ReadAddr是扇区地址，BlockSize固定为512字节，也就是说spi方式读扇区的函数没有BlockSize这个参数！

mahongtu0204 · 发表于 2015-5-20 10:36:50

回复【18楼】STM32VBT6:
---------------------------------
可是我测试我的SD卡，8G的，我先存进去大于G的文件，（6G多）
然后我用spi方式去创建一个文件，打开，写进去数据到文件，
创建和打开都是好好的，但是写数据进去的时候，有时会花很长的时间才能完成，大概几秒钟
有时候没有延时就完成了
不知道是fatfs的问题还是别的问题

STM32VBT6 · 发表于 2015-5-20 10:45:50

回复【19楼】mahongtu0204:
---------------------------------
数据多大？

mahongtu0204 · 发表于 2015-5-20 11:42:56

就是100个字节回复【20楼】STM32VBT6:
---------------------------------
就是100个字节

光少 · 发表于 2015-6-12 21:59:37

原子哥，我简单用了一下fatfs 0.11 和emwin，不挂载还好，挂载就不能运行了，程序在HardFault_Handler里，需要我上传代码吗

正点原子 · 发表于 2015-6-12 22:20:56

回复【22楼】光少:
---------------------------------
不用，八成是内存访问问题，堆栈溢出，指针未分配内存等。

ye781205 · 发表于 2015-6-13 11:36:58

标记备用。。。。。。

光少 · 发表于 2015-6-13 13:53:42

回复【23楼】正点原子:
---------------------------------
说的太对啦！我把汇编的0x00000400改成800就好了！！！！！

e8098 · 发表于 2015-7-14 11:06:47

多谢楼主分享，太有用了

wuyangisbest · 发表于 2015-7-14 14:09:01

写得真好。

fangzhe1992 · 发表于 2015-12-25 15:09:40

大赞。mark。

novice · 发表于 2015-12-26 08:44:53

我是做软件的，看到你们这么开心我实在是忍不住要打击你们，楼主的解决办法是不行的！
因为FAT32文件系统对单个文件的最大容量限制就是4G-1字节！所以无论你怎么折腾都不能够违背这个规则！

正点原子 · 发表于 2015-12-26 20:11:20

novice 发表于 2015-12-26 08:44
我是做软件的，看到你们这么开心我实在是忍不住要打击你们，楼主的解决办法是不行的！
因为FAT32文件系统 ...

是卡容量，不是单个文件大小。你理解错了。

void · 发表于 2015-12-29 10:49:23

正点原子发表于 2014-7-18 22:50
我也分享一点今天发现的经验.
fatfs V0.10a以及V0.10b存在一个bug
就是fclose/fclosedir之后,没有调用 ...

原子哥，我看0.10b的f_close用unlock_fs，应该就不用LEAVE_FF了吧。
但是在UCOS下使用FatFS各种有问题。。。
用FatFs自带的重入参数设置各种不可以。
因为内存比较紧张，我是想只定义一个FIL变量，然后使用它在多个任务中操作多个文件，
ff_rel_grant发送信号量，返回的err是OS_ERR_MUTEX_NOT_OWNER
逼得我用调度锁了

正点原子 · 发表于 2015-12-29 23:29:11

void 发表于 2015-12-29 10:49
原子哥，我看0.10b的f_close用unlock_fs，应该就不用LEAVE_FF了吧。
但是在UCOS下使用FatFS各种有问题。 ...

可以参考下我们综合实验的处理方式.

void · 发表于 2015-12-30 09:48:18

正点原子发表于 2015-12-29 23:29
可以参考下我们综合实验的处理方式.

我看实验56使用的还是UCOS II,每个文件都定义了一个FIL 结构体，一个FIL 结构体里都有一个
BYTE buf[_MAX_SS]，想着节约内存，只定义一个FIL，在UCOS III下多个任务操作多个文件。现在使用了调度锁暂时解决这个问题，不知道原子哥有没有啥更好的方法？

新手求助 · 发表于 2015-12-31 16:06:36

真是太感谢了，我最近也在做与FATFS有关的SD卡存储问题。

小冉進擊 · 发表于 2016-5-31 17:22:03

正点原子发表于 2014-7-21 23:58
没问题的，对大容量卡来说，这里是要除以512，再送给ARG的。
具体看代码：

原子哥有研究過FATFS+U盤嗎，我現在用STM32F446的OTG功能操作U盤，也有這種4G上線的問題，而且我看底層文件，也沒有SD那種大文件ReadAddress/512的機制。還是說現有的底層文件限制只能在4G範圍內操作？謝謝

luyongyun · 发表于 2016-5-31 21:41:10

感谢楼主和原子哥分享

Esbin · 发表于 2016-6-1 20:02:04

学习了，感谢分享

带我足够强大 · 发表于 2017-1-4 18:39:23

光圈电子科技-晓航-多多实验室发表于 2014-7-22 10:35
回复【8楼】KC_CEC:
---------------------------------
没有问题哦，我的FatFS仿真的时候地址存在r2寄存器 ...

MArk ,xiexiefenxiang

liuqishigou · 发表于 2017-1-5 10:12:19

多谢分享

Polychromatic · 发表于 2017-3-6 17:06:01

学习学习，谢谢分享~

1491430114 · 发表于 2017-3-13 12:30:09

曾经改过底层，能认出16G的SD卡，是不是改的这儿记不得了

ranfs · 发表于 2017-4-28 17:47:09

可以参考 ranfs fat文件系统

ranfs · 发表于 2017-4-28 17:48:03

ranfs 发表于 2017-4-28 17:47
可以参考 ranfs fat文件系统

ranfs.com

yu7622 · 发表于 2017-12-12 16:49:26

mark 写的真好

xy228 · 发表于 2018-12-1 10:38:59

我试了一下
这个方法可以，但是有个地方不好：“就是把unsigned long 无符号长整型变成unsigned long long 无符号64位长整型。”这种操作其实已经改变了FATFS的库函数的变量类型，我觉得最好别改库文件。
我用另一个方法做了测试，不需要修改这个变量类型的定义：

DRESULT disk_write (
BYTE pdrv, /* Physical drive nmuber to identify the drive */
const BYTE *buff, /* Data to be written */
DWORD sector, /* Start sector in LBA */
UINT count /* Number of sectors to write */
){}
这个函数传递的是一个sector值，在调用SD_WriteMultiBlocks(uint8_t *writebuff, uint64_t WriteAddr, uint16_t BlockSize, uint32_t NumberOfBlocks);这个函数的时候，我这里找到的例程是直接用这样的方式：
SD_WriteMultiBlocks(buff, BLOCK_SIZE*sector, BLOCK_SIZE, count);
因为sector本身是一个DWORD类型，是不是因为BLOCK_SIZE*sector的值在计算之后仍然默认是DWORD类型（这时候已经地址溢出了），然后在参数传递的时候才强制转换为uint64_t，其实等于是先发生了溢出，然后再传递？
所以我改成了这种方式：
SD_WriteMultiBlocks(buff, BLOCK_SIZE*(uint64_t)sector, BLOCK_SIZE, count);

这样处理并不需要更改integer文件里面DWORD的类型定义，测试后反正8G的SD卡读写到6G多的时候是没什么问题的。按这样处理的话，在BLOCK_SIZE为512的情况下，理论上应该能支持512*4G 大小的SD卡，不知道我理解的对不对？