FatFs F_Open Fails when Long File Name is enabled

[franck23]

Setup:

STM32H743

FreeRTOS

FatFs

8G SD card on SDMCC1 (FAT32 formatted)

Hi,

I have a problem with f_open which does not work when Long File Name is enabled (_USE_LFN = 2).

f_open(&MyFile, "TEST.TXT", FA_CREATE_ALWAYS | FA_WRITE) == FR_OK) returns FR_INT_ERR.

Looking into f_open, I can trace the error to dir_find() which returns the FR_INT_ERR flag.

However, find_volume() which is called just before is working.

If I disable Long File Name (_USE_LFN = 0), everything works fine.

I have tried to increase the MCU heap and stack and the stack of the thread managing the SD card with no effect.

Thanks for any help.

[Tesla DeLorean]

Are you using the current version of FatFs or the old one ST ships?

What precipitates the internal failure, a memory allocation issue, or one of structures on the media, or supporting functions.

[franck23]

I am using the one implemented by CubeMX.

I disable D-caching for the read buffer (which is not used by the time f_open() fails).

It doesn't look like a memory allocation issue.

The function clust2sect(fs, clst) called by dir_sdi() returns 0, which is then detected as an error.

It returns 0 because clst = 0 and fs->database = 0.

I have to admit I do not understand the file system enough to know what is normal or not.

[Tesla DeLorean]

Does the card pass CHKDSK type scanning? Could be corrupted.

I don't think the Internal Error is a result of a disk error, perhaps reading the wrong sector(s)

Again, you should probably migrate to current release of FatFs, ST ships a version known to fail on large media.

[franck23]

The issue may be that I have declared the read buffer in D2 SRAM.

I am not using this buffer yet, just the fact to declare it gets f_open to fail.

Also, if I declare another 32-bit aligned variable right before or right after the read buffer declaration, f_open works.

I must be doing something fundamentally wrong with the read buffer declaration!

Read buffer declaration (global variable):

// uint8_t Test __attribute__ ((aligned (32))); // f_open works when this line is active
 
uint8_t __attribute__((section(".dma_buffer"))) rtext[64] __attribute__ ((aligned (32)));
 
// uint8_t Test __attribute__ ((aligned (32))); // f_open works when this line is active

Linker file:

SECTIONS
{
 /* DMA buffers in RAM_D2. RAM_D2 D-Cache is then disable via MPU */
 .dma_buffer 0x30000000 :
 {
 KEEP(*(.dma_buffer)) /* keep variable even if not referenced */
 } >RAM_D2
...

at the start of main() I enable D2 SRAM as follow:

__HAL_RCC_D2SRAM1_CLK_ENABLE();
__HAL_RCC_D2SRAM2_CLK_ENABLE();
__HAL_RCC_D2SRAM3_CLK_ENABLE();

[JRobe.2]

You might double your Stack (0x800) and Heap (0x400) size.

[Tesla DeLorean]

ST ship R0.12c from 2017, that's likely the underlying problem

The DISKIO layer API changed, but they've had FOUR years to migrate... It's like herding cats uphill..

[franck23]

Hi JRobe,

Thanks for the help, but for test I have increased the MCU heap and stack to 0x2000 and the SD card task stack to 16k with no effect.

[franck23]

Yeah, I can see that the best solution would be to not use CubeMx for this.

But being at the end of this project with the deadline looming, I am reluctant to change the FatFs implementation...

If there is no other way to get it to work, I will have to remove the long file name option for this firmware and get back to it later.