BSP_SD_Init() fails - problem in SDMMC initialization ?

[Sasa1234]

Title updated to better reflect the root problem; was originally 'Riverdi 12.1" + TouchGFX 4.25 + FATFS not working'

---

Hi everyone,

I am working on a Riverdi 12.1" display board based on STM32H7 with TouchGFX 4.25 generated project.

Environment:

• TouchGFX 4.25

• STM32CubeMX generated project

• STM32CubeIDE

• Riverdi 12.1" board

• STM32H7

• FreeRTOS enabled

• Debugging with ST-LINK

Problem:
BSP_SD_Init() returns MSD_ERROR_SD_NOT_PRESENT.

In main.c:

uint8_t res;

res = BSP_SD_Init();

risultato = res;

if(res != 2)
{
    Error_Handler();
}

The value stored in risultato is:

MSD_ERROR_SD_NOT_PRESENT

Additional important behavior:

When I start a FreeRTOS task that accesses FATFS/SD, the display becomes completely black and TouchGFX no longer shows images.

This is my task:

void StartDefaultTask(void *argument)
{
    FIL file;
    UINT bw;

    for(;;)
    {
        SCB_CleanDCache();
        SCB_InvalidateDCache();

        if(BSP_SD_Init() == MSD_OK)
        {
            if(f_mount(&SDFatFS, SDPath, 1) == FR_OK)
            {
                if(f_open(&file, "log.txt", FA_OPEN_ALWAYS | FA_WRITE) == FR_OK)
                {
                    f_lseek(&file, f_size(&file));

                    char msg[] = "log entry\r\n";
                    f_write(&file, msg, strlen(msg), &bw);
                    f_close(&file);
                }
            }
        }

        osDelay(1000);
    }
}

If I completely comment out this task, TouchGFX works correctly and all images are displayed normally.

So:

• With SD/FATFS task enabled → display becomes black

• With SD/FATFS task disabled → GUI works correctly

Other details:

• SDRAM initialized correctly

• LTDC working before SD task starts

• QSPI memory mapped mode enabled

• FATFS enabled

• MPU configured with SDRAM framebuffer as non-cacheable

MPU configuration:

MPU_InitStruct.BaseAddress = 0xD0000000;
MPU_InitStruct.Size = MPU_REGION_SIZE_8MB;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;

Questions:

• Could this be a DCache/MPU coherency issue between TouchGFX and FATFS?

• Is there a known issue with Riverdi BSP + SDMMC + TouchGFX?

• Should SD buffers be placed in a dedicated MPU region?

• Is calling SCB_CleanDCache() and SCB_InvalidateDCache() inside the task causing LTDC framebuffer corruption?

• Is there a recommended STM32H7 cache configuration for TouchGFX + FATFS?

Any suggestion is appreciated.

Thanks.

[Osman SOYKURT]

Hello @Sasa1234 ,

I'm wondering whether the issue is related to TouchGFX at all.
The best way to confirm this is to test SD card initialization in a minimal project without TouchGFX, FreeRTOS, LTDC, or QSPI.
First, verify that BSP_SD_Init() works correctly.
If SD still fails in that setup, the issue is likely in the SDMMC/BSP/card-detect/hardware configuration rather than in the GUI.
Only if it works in the minimal project and fails after adding TouchGFX should cache/MPU/display interaction be investigated.

[Sasa1234]

Hi @Osman SOYKURT 

The issue does not appear to be related to TouchGFX.

As mentioned previously, BSP_SD_Init() already fails in the current setup, which points to a problem in the SDMMC peripheral initialization rather than anything related to the GUI, FreeRTOS, LTDC, or QSPI.

At this stage, the root cause is most likely related to the SDMMC/BSP configuration, card-detect signal, or underlying hardware setup.

I read this : Solved: STM32H757 SDMMC1 only works with M7 core - STMicroelectronics Community 

But I don't have idea how to do it!!!!

If anyone has experience with BSP_SD_Init() failures and knows how to resolve this kind of issue, any advice would be greatly appreciated.

[Osman SOYKURT]

Hello @Sasa1234 ,

I will move your message to another ST Community forum board, where you have a better chance to receive an answer.

[Peter BENSCH]

Moved from forum TouchGFX to  STM32 MCUs Embedded software because the question is not related to TouchGFX.

Regards
/Peter

[mƎALLEm]

Hello,

---

@Sasa1234 wrote:

• Should SD buffers be placed in a dedicated MPU region?

---

I don't have idea about how the SDMMC drivers have been implemented but, the data need to be located in region accessible by the SDMMC and that depends on which instance you are using SDMMC1 or SDMMC2. From the RM0399:

For example if the SD data to transfer are located in DTCM, the transfer won't be performaed as the SDMMCs have no access to that memory. So you need to check from your side.

---

@Sasa1234 wrote:

Is calling SCB_CleanDCache() and SCB_InvalidateDCache() inside the task causing LTDC framebuffer corruption?

---

I'm wondering why calling these APIs in a loop in that task! If you comment out these lines do you face the same behavior?