FreeRTOS CMSIS_V1 - SD Card File Open/Write Failure as Usage of SD Card Increases?

[CNesb]

Hello. I am working with the STM32F7, using FreeRTOS version 10.0.1, with CMSIS-RTOS version 1.02. The issue in question has been prevalent within my project for months, and the temporary workarounds I had previously designed aren't quite up to the project's standards anymore.

The device I work with has many different peripherals, and with that I have a variety of tasks that are expected to run in FreeRTOS, one of which is dedicated to interfacing with the FatFs library for opening, reading, and writing to files on an SD Card. However, SD Card failures are not an uncommon sight to see within this project. It seems that there at least a couple different things that can contribute to this communication failure:

1. When the total data written to an SD card approaches or surpasses about 2 GB (on a 32 GB card)
2. When a file is attempted to be created/opened when there are many other files of a similar name in the root FatFs directory

Normally, the SD card will operate as expected. When referring to a "failure", it seems that the FatFs library loses communication with the SD card, and hangs until a timeout on SDMMC_GetCmdResp1, on the line shown below:

}while(!__SDMMC_GET_FLAG(SDMMCx, SDMMC_FLAG_CCRCFAIL | SDMMC_FLAG_CMDREND | SDMMC_FLAG_CTIMEOUT));

After this timeout occurs (usually takes about eight seconds to officially timeout), the communication is totally interrupted, and doesn't seem to work again. I'm curious, has anyone had a similar issue to this? I am wondering if it could be tied to the time taken for a read/write to occur, and if that could exceed 10 ms for some reason (which is the time between my tick interrupts). To try and mitigate the time that the STM32 gets pulled away from communicating with the SD Card if a tick interrupt occurs, I temporarily assign the SD Card task to the highest priority, which surely is not the best solution. Still, even with this workaround failures still occur as described above. I feel as if I were to disable interrupts using taskENTER_CRITICAL then it may "solve" the issue, but that is not possible to do before writing/reading from the SD Card, as API functions are used to achieve this.

Any insight into this issue, or ways that I could mitigate/eliminate the problem would be greatly appreciated, as this has been giving me a headache for quite some time. I'm happy to elaborate on anything if needed. Thanks!

Carter

EDIT: I should also mention that when the issue spawns as a result of the amount of volume used on the SD Card, it does not matter whether the files get "deleted" or not. If I have ~ 2GB of data on the SD Card and I see the error occurring, when I delete all of the files the issue continues to persist. It is only when I reformat the SD Card that these problems disappear (until I write about 2GB again).

[dbgarasiya]

Follow below link

C:\Users\Graffin01\STM32Cube\Repository\STM32Cube_FW_F7_V1.15.0\Projects\STM32F769I_EVAL\Applications\FatFs\FatFs_uSD

[dbgarasiya]

you do no neet to format sd card to write files

[dbgarasiya]

my suggestions is not to use f_mkfs for write to sd card

[dbgarasiya]

just follow example already comes with software

[Garnett.Robert]

Hi,

I don't know if these ideas will help , but I had a fair bit of trouble with SD Cards and fatFS. In the end I found that the following fixed the problems:

• Use exFAT with long filename set to max (255).

• format the SD Card with Windows diskpart: format fs=exFat, label="Mylabel", unit=16k, quick, Note you can make the unit size anything you like, but select one that makes sense for the file sizes you are using

• Remember that you are limited to a fixed number of files/directories in the root. (< 255). So if you are writing lots of files then put them in a sub-directory as there is no limit. (I got caught out on this one. I should have known better as anyone over fifty should have remembered this DOS limitation.

My config file for fatFS is attached

 
 
 h

The other problem I encountered was that the HAL_Drivers interrogate the SD card at low speed (400 kHz) to work out what sort of card it is. If the card you are using is a fast one >25 Mhz then the HALS Driver sets the SD Clock to 100 MHz or more. The higher speeds need an interface chip between them and the SD Card and SD Clock phase correction to ensure read data lines up with the clock edges. Cards that stream use both the rising and falling edges so timing is critical. Track layout is critical. If you are connecting the SD Card through a breadboard then you must keep clock speeds below a couple of meg.

I hacked the code to make the clock speed a maximum of 25 MHz as I had the SD Card directly connected with no clock feedback, or phase correction delay.

Best regards

Rob