2021-05-31 09: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.
2021-05-31 09: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.
2021-05-31 09: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.
2021-06-01 09: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();
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.
2021-06-01 11:21 AM
You might double your Stack (0x800) and Heap (0x400) size.
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.
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..
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.