TouchGFX breaks SDMMC DMA transfert for FatFS using SD card

[VBurs]

Hi,

I have a STM32F779BI on a custom board that communicates with a LCD display using the LTDC interface in 16bits (480x272). I am using a single buffer inside the RAM of the MCU. So far TouchGFX works pretty well but once i activated the Software package for touchgfx inside Cubemx, i see that a "MX_TouchGFX_Init();" is added in the Main init section and i have to manually call the "MX_TouchGFX_Process();" in a task when all my board is up and running and can finally start the drawing process on the LCD.

My problem is that i have a task for logging data on a SD card using FatFS. Since i am using FreeRTOS, i had to implement the writes and Reads using the DMA on the SDMMC. This works pretty well too when touchgfx is not initialized ("MX_TouchGFX_Init();") and started ("MX_TouchGFX_Process();").

At first i thought it was a problem of NVIC priority for the SDMMC DMA versus the DMA2D interrupt priority. However, i made sure to give the DMA2D a priority less than for the DMA SDMMC and it still don't work.

The reason i know it's not behaving correctly is that FatFs return "FR_NO_FILESYSTEM" when doing a "f_open()". Normally, the FatFs generated by CubeMx does not need any modifications and if it breaks, is usually due to a lower layer (DMA transfer in this case).

Has anyone experienced problem with the Sdcard when using touchgfx in this communiation: SDMMC+DMA+FATFS+FReeRTOS+TouchGFX?

I have provided the project as is where you can look into my cubemx file for settings.

Thanks in advance for the help.

[CForo.1]

Hello,

I use a STM32F746G-DISCO and i have a similar problem.

My program uses FreeRTOS + SDMMC + FatFS + TouchGFX, when using RTOS and TouchGFX, FatFS functions don't work properly.

I'm trying to find a issue.

[Martin KJELDSEN]

Hi,

We have a meeting with CubeMX this week to talk about this specific issue

/Martin

[VBurs]

Amazing news! Looking foward for a solution.

[VBurs]

Any solutions?

[Bob Bailey]

Any news from the meeting? Workarounds, beta versions, alternatives?

Bob

[Bob Bailey]

@Martin KJELDSEN​  any news on this topic? Any success trying it on the disco board? Any feedback from the CubeMX people?

Thanks

[VBurs]

@Martin KJELDSEN​ , I am still waiting for a solution...our product is being delayed because that feature (having an LCD + SD card working) is necessary...Thanks for answering back

[Bob Bailey]

@Martin KJELDSEN​  posting again to keep this at the top.

Any thoughts? Anyone in the forum have any workarounds? @HP​ ?

Thanks,

Bob

[HP]

So, it seems that the DMA transfers somehow break the timings required by the FAT.

Now, I haven't done any testing on this whatsoever, so my thoughts are merely... thoughts.

As far as I can see we haven't yet tried disabling tGFX while we're writing, have we?

If we're on the LTDC then disabling the DMA2D interrupt should be enough to stop the tGFX process being driven forward (I might be wrong but you get the idea)

So the workaround (which it definitely is) would be to:

1. display an indication that we are writing
2. stop tGFX
3. do the actual writing
4. re-enable TGFX
5. clear the message

I acknowledge that this will most likely result in screen tearing or some other interesting graphical artifacts - but it might be worth a shot?

[Bob Bailey]

Depending on timing, any pauses should be able to be between frame-renders. It depends on what the root of the issue is.

Still waiting on more feedback from the staff, we need to keep this thread near the top, perhaps we will hear from another community member with some ideas/workarounds.

My project is upcoming, and this would be a real show-stopper.

Bob