2020-10-27 01:12 AM
I am using STM32F767NIH6 board.
I would like to apply SD card this time.
It works well in non os, but in free rtos, the sd card fails.
if(HAL_GPIO_ReadPin(SD_DETECT_GPIO_PORT, SD_DETECT_PIN) == 0)
{
if(f_mount(&SDFatFS, (TCHAR const*)SDPath, 0)!=FR_OK)
printf("mount err\r\n");
else
{
printf("mount ok\r\n");
if(f_open(&SDFile, "test.txt", FA_CREATE_ALWAYS | FA_WRITE) != FR_OK)
{
printf("Failed to open Write file\r\n");
}
else
{
printf("Opened Write file successfully\r\n");
//Write data to text file
res = f_write(&SDFile, wtext, strlen((char *)wtext), (void *)&byteswritten);
if((byteswritten == 0) || (res != FR_OK))
{
printf("Failed to write file!\r\n");
}
else
{
printf("File written successfully\r\n");
printf("Write Content: %s\r\n", wtext);
}
f_close(&SDFile);
}
f_open(&SDFile, "test.txt", FA_READ);
memset(rtext,0,sizeof(rtext));
res = f_read(&SDFile, rtext, sizeof(rtext), (UINT*)&bytesread);
if((bytesread == 0) || (res != FR_OK))
{
printf("Failed to read file!\r\n");
}
else
{
printf("File read successfully\r\n");
printf("File content: %s\r\n", (char *)rtext);
}
f_close(&SDFile);
}
}
When applied in freertos, an error occurs with a return value of 3 in f_open.
FR_NOT_READY, /* (3) The physical drive cannot work */
I don't know what to do when a problem like this happens.
Please understand even if the translation is a little strange.
2020-11-02 09:37 AM
For better or worse I'm having this issues related to this as well. I've opened a support ticket and I'll send an update to this thread. Here is where I"m at.
STM32F446RE using STM32CubeMX/IDE (FW ver 1.24.1) with FreeRTOS, SDIO w/DMA, FatFs + others. We have been using FatFs successfully for about a year with a single task (we have 3 tasks + IDLE). As we have started trying to use FatFs on a second thread I noticed right away some wonkyness. I've gotten around it by just suspending primary task while the second task needs to interacted with the file system (during program and test). We are trying to expand the capabilities of the product and decided that we need to have FatFs interacting in both tasks at the same time. I've seen other posts by clive1 (NFA crew) where it was stated that the FatFs is non-reentrant but I see on the FatFs web site where it states that it is reentrant (http://elm-chan.org/fsw/ff/doc/appnote.html#reentrant) and in the ST application note (UM1721) that it is reentrant as well as long as ff_cre_syncobj(), ff_del_syncobj(), ff_req_grant() and ff_rel_grant() are added to the project. I can also see that these have indeed been generated with prototypes in ff.h:
/* Sync functions */
#if _FS_REENTRANT
int ff_cre_syncobj (BYTE vol, _SYNC_t* sobj); /* Create a sync object */
int ff_req_grant (_SYNC_t sobj); /* Lock sync object */
void ff_rel_grant (_SYNC_t sobj); /* Unlock sync object */
int ff_del_syncobj (_SYNC_t sobj); /* Delete a sync object */
#endif
And actual code in syscall.c with timeouts on the semaphore acquisition of 1000 ticks. Our tick rate is 1000 Hz so if my math works out this is a one second timeout. I have created histograms of 50,000 writes and can see that 99.4% of all writes are less than 40ms with the longest write being 190ms. Even with this there still have been FatFs wonkyness.
So in an attempt to mitigate this issue (though I shouldn't need to), I wrapped FatFs calls in both tasks with a FreeRTOS mutex (that I named xMutexFileSystem). This didn't help either.
I've also increased the _FS_TIMEOUT to 5000 ticks, way way more than is needed and still the problem persists.
Also, it should be noted that we have redefined malloc, free, new and delete with FreeRTOS equivalents, so we do not think that there are issues with using [sn]printf funcitons.
Here are my current hypothesis:
Because the SDIO is using DMA and in spite of the use of semaphores in the FatFs code once a semaphore is released and the other task tries to use FatFs the DMA channel is not protected.
Definition of wonkyness:
This issue happens when there is lots of file IO going on, like one task writing 50,000 100 byte entries in a loop while another task writes every 250ms. This process takes several minutes to complete and sometimes takes a minute or two unit the issue occurs. The result is that one task will return FR_DISK_ERR when calling f_open or f_write.
I have also seen issues when listing a directory (ssing f_opendir and f_readdir) with hundreds of files in one task while another task is writing to a files.
Jacob
2020-11-02 06:03 PM
Another point that is significant that I left out...
If I suspend one task or the other everything in the given task works fine. Its only when both tasks are running that the file system fails. Once it fails it cannot recover and we are getting hit with 1 second delays every time a file system call is made (due to the semaphore timeout).
Jacob