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.

[VBurs]

Any solutions?

[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_it]

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

[EMitu]

I've got the same issue. FatFS doesn't work correctly as with SD card, and both USB on STM32F746-Discovery too.

[Breeze1]

Have similiar problem....mark

[EKari.1]

Hi,

I have similar problem. Can anyone help me?​

[OWLchan]

So has anyone solved this problem?

[JHawk.1]

Hi all

​

I'm assuming not, given the lack of replies for a while, but have there been any updates with this? I'm working on a similar situation on the STM32H735G-DK development board, using the animation texture mapper touchgfx demo and cubemx to set up SDMMC/FatFS. In my case, the error appears to occur while mounting the SD card, specifically that it is not correctly reading the boot sector of the SD card, so it's reporting no file system found. I was able to get the majority of the boot sector to read correctly, but not the first few bytes which are used within the check_fs function in ff.c. This seems to cause FatFS to assume the mounted SD card does not have a valid FAT_VBR partition.

As mentioned above, it seems touchgfx is the main culprit as I have been able to get SD reading and writing working fine without it, but the suggestion of disabling interrupts for DMA2D and/or LTDC while reading from the SD, to avoid touchgfx influencing the read, does not appear to help from my limited testing.

Any help would be greatly appreciated.

[JHawk.1]

From a bit more digging I found that something in the D cache setup seems to have been causing the issue. Adding 'SCB_DisableDCache()' before and 'SCB_EnableDCache()' after any SD card operations seems to solve this issue for me without interfering with TouchGFX in any way. I've only done minimal testing so I cannot guarantee that this solution will work in all situations or be stable long term (I'm not 100% sure what the D-Cache is even used for).

If anyone finds any more information about this, or why disabling the D cache works, I'd be very grateful.

[JSext.1]

Morning all, I have just started working with SD card on an STM32H747i-Disco this week, and run into similar issues. From a brief study between a working example without Touch GFX and a similar version with TouchGFX, I have noticed the SDFatFS pointer has no data and consequently cannot do anything. I am investigating this now, but not familiar where these are defined as there a multiple files to go through. Has anyone else noticed this? 

[JHawk.1]

I have no idea if it will work for you, your issue sounds slightly different to what I found, but as I put above try disabling the D cache before an SD card operation, and enabling the D cache again afterwards.

[JSext.1]

Thanks for the tip. I gave it a try, even around the  MX_SDMMC1_SD_Init();

 MX_FATFS_Init() commands. Had no effect unfortunately. This is what I obtain through debug (all zero's (top)) and what I expect is at the bottom...

[JSext.1]

Just wanted to share with you a quick update. Disabling and re-enabling D-Cache did actaully resolve the issue, so like to thank you again. I only realised by accident that there was also a secondary factor in parallel which was resulting in the same error. This was SDIOCLK divide factor which only became apparent when I tried another (but unknowingly faster SD card) since the program worked as is. Only by changing the SDIOCLK divide factor to 4 (from 0) did the original SD card work. At least its resolved the problem and very stable now. Thanks

[Piranha]

A proper D-cache maintenance is explained there:

https://community.st.com/s/question/0D53W00001Z9K9TSAV/maintaining-cpu-data-cache-coherence-for-dma-buffers

[JHawk.1]

With regards to that explanation then, is that something that we should implement manually before/after FatFS interactions? I'd have thought that level of D-Cache management would have been done by the FatFS library if it was necessary?

[Piranha]

The D-cache maintenance code should not be in the generic library, but in the DISKIO driver for the specific platform. And, as in this case the driver is implemented by ST, it is a broken bloatware. Therefore the real answer is - toss out the code implemented by incompetent fools and replace it with a decent one.