STM32F7 SDCard Open File After a specific number of files

[Murat]

Hello, 

I am using STM32F746 MCU and trying to use SDCard in DMA mode using FatFS.

This MCU has Cache also so for any conflict between DMA and the cache, I have disabled the cache. 

I am just trying to create files in an infinitive loop at startup. (Create, Write, Close, Increase File Name). 

But after a while I am not able to create file and f_open() returns DISK_ERROR; It always returns error for the same file number.

If I create files with short file names, it take long time to have the error.

(For example; If file names length is 15, I am starting to have error after 1500th file, but the file names length is 150, having error after the 600th file ).

The format is FAT32 so I would expect to have 65K files in a directory.

What I see, if the file name is aroung 150, after the 600th file, I dont get DMA_Complete Callback(and timeouts) and when I ask the SDCard state using HAL_SD_GetCardState(), it returns HAL_SD_CARD_SENDING.

Any suggestion?

Thank you.

[Murat]

I have just tested the FatFs_uSD example from STM32Cube_FW_F7_V1.11.0 library (Keil MDK), this example is a tiny example to test the SDCard, and I am seeing the same problem.

Nobody experienced it before unless it is not about the SDCard? Thanks.

[Tesla DeLorean]

Instrumenting the read/write routines in DISKIO to report upon failure would tell you if you have a failure on the IO side.​

[Tesla DeLorean]

If you use LFN they consume multiple entries in the directory, including a short variant.

I would tend to avoid putting lots of files in the root directory. The system will become slower the more files in must step through to create new ones, or find files/directories.

>>Nobody experienced it before unless it is not about the SDCard?

Bugs in software really aren't a popularity contest. Responsiveness of the forum is dependent on people on different sides of the planet, whose night/day are different.

[Murat]

Thank you Clive,

>> If you use LFN they consume multiple entries in the directory, including a short variant.

Thank you for the recommendation, I disabled it and tested with short names but still the same issue.

>> Bugs in software really aren't a popularity contest

Sorry, I meant STM32F7 and FatFS should be used by thousands/millions so if there was a limitation, it must be reported before. It should be about my environment.

[Murat]

Hi again, it seems it is about my SDCard, I dont see an issue with a different microSD.

[Murat]

Hi again, I have run the same test with Arm Keil Exampe which uses MDK Flash File System (MDK\Boards\ST\STM32F746G_Discovery\Middleware\FileSystem\File_Demo), it seems there is no problem with this file system.

So, as final, all of my SDCards works well with Keil Flash File System example.

One of the SDCard does not work with FatFs_uSD example from STM32Cube_FW_F7_V1.11.0.

Where to blame? SDCard or FatFS :)

[Tesla DeLorean]

Cards come with all sorts of functionality, speeds and capabilities. The library and examples perhaps use some overly optimistic​ settings, rather than fully decode the feature set reported by individual cards.

The engineers working on the code likely have a small subset of cards to test/evaluate with, and it is probably unreasonable to cripple performance of everything to accommodate cheap/crappy cards.

In commercial code you might have to recognize cards by make/model and special case them with a black list, or advise your technical support team to tell a customer to select better cards.​

[Danish1]

There are "counterfeit" uSD cards which report a large capacity but then writes to many (higher) sector numbers simply fail. (The seller relies on the fact that many people don't fill up their SD card, or will only have problems a long time after the seller has moved on).

But if that were the problem, I'd expect MDK to fail as well as FatFS -- if and only if you're writing the same amount of data in the files and not just creating short files in your MDK test.

Was the different (working) SD card a different capacity?

My first suspicion would be a potential bug in FatFS, which could happen e.g. if the directory length grows beyond 1 cluster. Does that sound credible?

A 15 character file-name would require 2 entries for the long-file-name, with 1 more for the 8.3 name i.e. total of 3

So 1500 15-character filenames = 4500 directory entries, each 32 bytes long = 144k

A 150 character file name would require 12 entries for the long-file-name and 1 more for the 8.3 name i.e. total of 13

And 600 filenames = 7800 directory entries, each 32 bytes long = 250k

Now cluster sizes are more like 2k to 16k, so that doesn't sound likely.

But there could be a bug where e.g. the long-file-name is in one cluster and the corresponding short-file-name is in the next. Different uSD capacity might lead to different cluster size.

What else might go wrong?

I suppose if you're generating these long file names in sequence. And there's an algorithm to generate the 8.3 name from the long name. Maybe it's a weakness there, because the file-system has to ensure that the 8.3 names are unique. And I guess your sequence means the names start out largely similar.

Bugs are not easy to find. You would need to delve deep into the library to discover the point where FatFS flags the error. And then find out why it flagged the error. And then find out what was wrong to cause the error to be flagged. And then find out when and how the wrongness happened.

If you do find something that looks wrong in FatFS, please do report back, so FatFS may be corrected.

Hope this helps,

Danish

[dbgarasiya]

you can change .ioc setting for use of long file name