STM32H7: FatFs mounting fails when using FreeRTOS + SDMMC

[SimpleMa]

I am working with an STM32H743VIT6 and I am trying to migrate an existing bare-metal LVGL + SDMMC + FatFs project to FreeRTOS + LVGL + SDMMC + FatFs

In my previous bare-metal project, the SD card worked correctly.

However, after creating a new project using STM32CubeMX with FreeRTOS + SDMMC + FatFs, the FatFs mount operation fails from the beginning.

The problem occurs when calling:

f_mount(&SDFatFS, SDPath, 1);



void LVGL_Task(void *argument) {
  (void)argument;

  printf("LVGL Task START\r\n");

  FRESULT fres;

  printf("before f_mount\r\n");

  fres = f_mount(&SDFatFS, (TCHAR const *)SDPath, 1);
  printf("after f_mount, result = %d\r\n", fres);


  if (fres == FR_OK) {
    printf("SD success\r\n");
  } else {
    printf("SD fail\r\n");
  }

  printf("before ui_init\r\n");

  ui_init();

  printf("after ui_init\r\n");

  while (1) {
    uint32_t delay = lv_timer_handler();

    if (delay > 1000)
      delay = 10;

    osDelay(delay);
  }
}

 

I have placed the buf address in AXI SRAM and confirmed that the address is correct through UART printing
 

Linker:

/* Specify the memory areas */
MEMORY
{
  DTCMRAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
  LVGL_RAM (xrw) : ORIGIN = 0x24000000, LENGTH = 320K
  SD_DMA_RAM (xrw) : ORIGIN = 0x24050000, LENGTH = 64K
  RAM (xrw) : ORIGIN = 0x24060000, LENGTH = 128K
  DMA_RAM  (xrw) : ORIGIN = 0x30000000, LENGTH = 64K
  RAM_D2   (xrw) : ORIGIN = 0x30010000, LENGTH = 224K
  RAM_D3 (xrw)      : ORIGIN = 0x38000000, LENGTH = 64K
  ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
  FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 2048K
}


fatfs.c:

/* USER CODE BEGIN Variables */
__attribute__((section(".SD_DMA_RAM")))
__attribute__((aligned(32))) FATFS SDFatFS;

char SDPath[4];

/* USER CODE END Variables */

After a timeout of 30 seconds, SD fail will be displayed

 

 

Is there something wrong with the configuration of my STM32cubemx? Here are pictures of my various configurations

 

 

 

 

 

 

 

 

I have enabled D-Cache, but I managed the MDMA_buf address with an MPU to prevent D-Cache from accessing it. My LCD's DMAobuf also works this way, so there is no problem

I have already confirmed that the hardware and SD card itself are working because the previous bare-metal implementation can mount and read the same SD card successfully.

 

[AScha.3]

>I have already confirmed that the hardware and SD card itself are working because the previous bare-metal implementation can mount and read the same SD card successfully.

So hardware seems ok/working, just : what pin speed setting is used now, vs your previous version ?

• I found it often working only at pin setting: medium speed + pullups ON (all lines to sd-card).
• set sd-clock 50 MHz  (50MHz is standard maximum)

 

Otherwise i would try : without D-cache and MMU ; (just to exclude any wrong adress etc.)

[SimpleMa]

Hello AScha.3:

​This is my circuit diagram and GPIO pin configuration.There is an external pull-up on my circuit diagram, and I have tried to reduce the speed to medium speed, but it still doesn't work. I have also tried turning off both MPU and D-ACHE, but it still doesn't work

 

I've been stuck here since I debugged, and the comment says /* Wait that the reading process is completed or a timeout occurs*/  That is to say, reading failed, resulting in timeout and return error

 

Is there anything in the BSP_SD_SeadBlocks_DMA() function that I haven't modified

Best regards,
Simple Ma

[Andrew Neil]

Have you looked-up what that return code means?

Have you stepped through f_mount to see exactly where it fails, and why?

Have you tried a logic analyser on the SD-Card interface - compare & contrast the working & non-working cases ?

[SimpleMa]

Hello Andrew Neil :

I found out what the return value of the function f_mount () represents. It returns an enumeration definition of type FRESULT, and returning 1 indicates a hardware error has occurred. I searched down and found that the problem was in the SD_dead() function

 

This part of the code has been waiting for ReadStatus to be set to 1. I checked and found that it is set to 1 in the callback BSP_SD_SeadCpltcallbacks (), which is called by HAL_SD_RxCpltcallbacks (). The top-level call is made at HAL_SD_IRQHandler() in stm32h7xx_it. c. That is to say, the MDMA interrupt callback did not execute, so ReadStatus remained at 0.

 

I asked ChatGPT and it told me about this post 

I will follow the instructions in this post to set ReadStatus=0; Putting it in front of BSP_SD_SeadBlocks_DMA() still doesn't work

 

 

 

My previous bare metal routine SD_COCK was set to 20MHz, so I modified the current version to also set SD_COCK to 20MHz (bus clock set to 120MHz, frequency division set to 3), SD_CLOCK=120/(2*3)=20Mhz ), Then I used a logic analyzer to capture the signals of these two versions

SUCCESS:
 

 

FAULT:

 

 

I found that the CK signal and CMD signal in front of them are the same, except that the CK signal cycle of the Success version is 250us and the CK signal of the Fault version is 83us.

After 700ms, the Success version was able to retrieve the contents of the SD card normally, while the Fault version waited for ReadStatus to be interrupted and the callback function to be set to 1


It seems that there is a timing issue with the CK and Data signals in this Fault version

I don't understand why this problem occurred. I have tried to modify it according to the post, but it still hasn't been successful. Or is there a problem with my stm32cubemx configuration

 

Best regards,
Simple Ma

[Andrew Neil]

 

[db16122]

From bare-metal LVGL + SDMMC + FatFs project to FreeRTOS + LVGL + SDMMC + FatFs, It seems FREERTOS added lead to read fail while the hardware setting remain no change.

Any check list can be shared about what have been changed from the project side? Does the FreeRtos setting change the SD inialization sequence? 

[SimpleMa]

Hello db16122:

I want to develop an application that combines an LCD, LVGL, and FreeRTOS. I plan to store some resource files, such as images, on an SD card and then use LVGL's FatFs interface to load these images.

In my previous bare-metal project, this approach worked correctly. At that time, I did not use MDMA for SDMMC, so I did not encounter any problems.

Now I am migrating the project to a FreeRTOS environment, where MDMA is required for SDMMC. The main difference is that, with FreeRTOS, the SD card must be mounted after the FreeRTOS scheduler has started, so the mounting process needs to be performed inside a task.

I also rely on the MDMA interrupt callback to determine whether the SD card operation has completed successfully. However, I am currently stuck at the MDMA stage because the interrupt callback is never triggered.

Therefore, I suspect there may be a configuration issue with MDMA, SDMMC, or the related interrupt settings.

Best regards,
Simple Ma

[AScha.3]

​@SimpleMa ,

i forgot :

• try without D-cache, MMU
• and no DMA 
• and SD 1-bit mode

these been my settings : (but with Azure Rtos + Filex , but similar to freertos + fatfs )

(clock → 50M )