FatFs F_Open Fails when Long File Name is enabled
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-05-31 9:01 AM
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.
- Labels:
-
FatFS
-
FreeRTOS
-
STM32H7 series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-05-31 9:13 AM
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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-05-31 9:55 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 9:49 AM
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();
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 10:46 AM
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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 11:21 AM
You might double your Stack (0x800) and Heap (0x400) size.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 11:43 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 12:06 PM
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..
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 12:17 PM
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.
