cancel
Showing results for 
Search instead for 
Did you mean: 

FatFs F_Open Fails when Long File Name is enabled

franck23
Senior

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.

8 REPLIES 8

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
franck23
Senior

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.

franck23
Senior

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();

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
JRobe.2
Associate III

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

franck23
Senior

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.

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..

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
franck23
Senior

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.