STM32H7 FatFS f_write fails at low-level disk_read operation

[rtonet]

Hi ST Community.

I am using an STM32H725IGK MCU on a custom board. My board has a uSD card slot connected to the SDIO pins, and I am using SDMMC1 peripheral. I am also using FatFS to use a filesystem on the uSD card.

I can operate the SD card properly most of the time. I can mount, format, create files and folders, and read and write to files. However, sometimes, some operations fail. Normally, it's either f_write or f_lseek. They fail at the low-level disk_read() operation. I do not understand why.

I will share my system configuration:
- Clock MUX:

- SDMMC Parameters:

The clock divide factor of 2 gives 32 MHz. I also tried setting the clock to 16 MHz and 8 MHz, but the problem persists.

- SDMMC GPIO settings:

I also adjusted the output speed of the pins to guarantee the signal integrity is good, but the issue remains.
- FatFS defines:

- FatFS Advanced Settings:

My system also utilizes FreeRTOS, and I use semaphores to ensure that only one task accesses the SD card at a time. I have the FS_REENTRANT disabled.

I tried SD cards from different brands and different sizes. It seems that 16 GB cards work better, but still fail. The 32 GB fails more often.

Is there a limitation on the number of bytes that I can use on f_write or f_lseek? Is there a problem with my configuration that I'm not seeing? Do I have to use multiples of the maximum sector size, 512, in my configuration?

Any help is deeply appreciated. I've been stuck with this issue for a while now.

 

[AScha.3]

Hi,

just 3 notes :

- for bigger cards ( > 16GB) exfat should be enabled, because these cards usually are in exfat format.

- dont format the cards, usually 

- pin setting for all pins to the card : try medium or med./high speed , and pullup ON .

[rtonet]

Dear AScha.3, thank you for your reply.

- I started with exFAT first, but it still had the same issue.

- Why not format the cards? Can you explain why it is important? I usually format on Windows, and if needed, when the card is inserted, I also format using the FATFS function.

- Currently, I'm testing with 8 MHz and with low speed to guarantee that the signals are perfectly squared and well formed. Still, the problem remains. I have hardware pullups.

Best regards.

 

[AScha.3]

Hi,

>Why not format the cards? Can you explain why it is important?

usually every new card is formatted, to the best type of format variants for this card.

So formatting without any need makes card uasully worse, or best case , same as before.

And on windows (i would not trust any product from MS ) should be used the "official" SD-card format program,

https://www.sdcard.org/downloads/formatter/

>> It is strongly recommended to use the SD Memory Card Formatter to format SD/SDHC/SDXC/SDUC Cards rather than using formatting tools provided with individual operating systems. In general, formatting tools provided with operating systems can format various storage media including SD/SDHC/SDXC/SDUC Cards, but it may not be optimized for SD/SDHC/SDXC/SDUC Cards and it may result in lower performance.<<

So now imagine, what the mkfs will do "optimized" format for the card...

 

+

> signals are perfectly squared and well formed. Still, the problem remains.

So i would try a program version, where multitasking is stopped , while card access running;

just to verify, it has nothing to do with task switching etc.

Because usually read/write problems are coming from hardware issues, so you get them always/often.

Having only sometimes an random error indicates more likely a software problem.

 

[MFARH.1]

Hello @rtonet ,

What does the  f_write or f_lseek function return in case of failure?

Reagrds,

Maher

 

[rtonet]

Dear MFARH.1,

f_write, f_lseek and f_sync (which also fails sometimes) return FR_DISK_ERR. I traced the problem to an SD_read timeout. I currently have the timeout set to 1 second, instead of the default 30 seconds. The last test it timed out when calling BSP_SD_ReadBlocks_DMA function. The ReadStatus flag did not change from 0 after 1 second when it failed. My test lasted about 25 minutes before it failed.

[MA4]

Hello,
Can you try with 50MHz clock ? It's the recommended clock for High speed SD card.

 

[rtonet]

Dear MA4,

I'm afraid that this will not be a good option for me. When checking the signals on the oscilloscope, at 32 MHz, I already have some ringing on the bits, with VERY_HIGH speeds. When reducing to low or medium, the bits do not form too well. I may have to work with lower speeds.

[rtonet]

I have done a test that seems to indicate that the issue is not on the hardware. Once the SD card was detected, I opened a file and started writing 2048-byte blocks with f_write, every millisecond, and did not see any issues, even for 1-hour tests. Generally, the error manifests in less than 30 minutes.

In my main code, I'm experiencing issues because the context is slightly different. I'm running data acquisition sessions. For each session, I create a new file. After file creation, I add a file header which has a different size depending on the session configuration. After that, I start to write blocks of powers of two sizes. Normally, 256, 512, 1024, 2048, and 4096 (maximum). I do f_sync every 5 seconds.

Can the problem be related to cluster misalignment associated with the header size? That may corrupt the FAT and generate the error?     

[MA4]

Did you try to set a breakpoint in HAL_SD_ErrorCallback to see if you have an error in hsd->ErrorCode ?

[MA4]

Is your buffer in an accessible memory ?

[rtonet]

Dear MA4,

My buffers are in RAM_D1. It seems that the problem is related to threads. When only the SD card thread is active, the system operates correctly, even when writing 4096 bytes every 2 milliseconds. I already tried setting the SDMMC interrupt priority higher than all the others, but it still does not solve the issue. By setting the SD card thread with the highest priority, I avoid errors. However, the rest of the system eventually fails.

I need to better understand the impacts of the other threads on the SD card operation and vice versa.